What's new

Unbound unbound_manager (Manager/Installer utility for unbound - Recursive DNS Server)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

There are many things I do not understand....but nothing in the sermon you just provided answered my question(s) nor explains why the .conf file behaviour is behaving as it is (at least not in a way that I understand clearly).

Naturally I would have expected and still do expect that unbound is passive and it only acts on inputs it is provided...it is not AI.....but then how is it explained on then why when starting the tunnel via the vpn 1 call would the .conf file duly edited (by me) be overwritten with whatever VPN IP address is set in the GUI? That is really the question I have...thank you.
What is the alternative IP address you are putting in the conf file (where are you getting it from)? The script will fetch the live value from the ip route command for the VPN client number you give in the menu prompt (e.g. vpn 1). What's the purpose of overriding it with a different IP?
 
What is the alternative IP address you are putting in the conf file (where are you getting it from)? The script will fetch the live value from the ip route command for the VPN client number you give in the menu prompt (e.g. vpn 1). What's the purpose of overriding it with a different IP?

Thanks @dave14305 ....this clears it up instantly....I obviously didn't know that the script fetched the live IP address and thought that the .conf file needed the IP address hard-coded in for the tunnel to be configured and to work properly....ah the things I do not understand....haha

When I do a DNS leak test if left well enough alone, the my WAM address is still the one that shows...I believe I read that the VPN server ought be the one that is listed.....so I thought I needed to reconfigure and wanted to test a different server......

thanks as always.....
 
Why when starting the tunnel via the vpn 1 call would the .conf file duly edited (by me) be overwritten with whatever VPN IP address is set in the GUI? That is really the question I have...thank you.

1. The command 'vpn 1' doesn't physically start/initiate any VPN Client tunnel.

2. Computers are dumb - they only do what you request them to do , so you invoking the command 'vpn 1' tells the script to retrieve the appropriate VPN Client Gateway IP address and insert it into the 'unbound.conf' file, so unbound now knows which gateway to use.
 
1. The command 'vpn 1' doesn't physically start/initiate any VPN Client tunnel.

2. Computers are dumb - they only do what you request them to do , so you invoking the command 'vpn 1' tells the script to retrieve the appropriate VPN Client Gateway IP address and insert it into the 'unbound.conf' file, so unbound now knows which gateway to use.

Thank you...

I knew that (1) didn't start the tunnel....but I didn't know that (2) occurred (automagically) obviously....thus the hardcoded misperception .conf file edit.
 
@Martineau - this is coming from a big fan of your unbound script (which works wonders for me) and your several other contributions to the community. However, please let me share a concern related to a previous comment on the forum.
First of all, you, programmers are blessed not only with the technical smartness, knowledge, desire and drive to share, to make things easier for the masses, but also with the patience and willingness to support your work (against all odds, and/or common sense at times.) Thank you so much for that!
That being said, your second bullet on post #1723 above, concerns me - "2. Computers are dumb - they only do what you request them to do". That leaves me waking up in the morning and looking at the TVs, smartphones and other computer based entities that surround me with some sense of unease.
To make it short, may I kindly request that you change the 'dumb' part of the statement to something else? i.e. 'sneaky' or other suitable adjective of your choice... After all 'dumb' as they are they don't always do what we request them to do :).
 
They always do what we ask them to do (as much as possible, if they are working correctly, of course).

Sometimes what we think we're asking and what we direct them to do doesn't jive with the inputs they expect and the output they're capable of. :)
 
They always do what we ask them to do (as much as possible, if they are working correctly, of course).

Sometimes what we think we're asking and what we direct them to do doesn't jive with the inputs they expect and the output they're capable of. :)
Case in point, my script will quite happily get stuck in a never ending loop because I forgot to write a break condition!
 
Had to reinstall unbound from scratch - seems to be calling a non existent file unbound.conf.addgui during install and then aborting. This is after a clean install from scratch after manually deleting all entries and directories relating to unbound. This should be easily repeatable for anyone installing Unbound from scratch. This was done using the single line install from Github.

Code:
Adding 'include: "/opt/share/unbound/configs/unbound.conf.addgui"  '/opt/var/lib/unbound/unbound.conf'
Adding 'include: "/opt/share/unbound/configs/unbound.conf.add"  '/opt/var/lib/unbound/unbound.conf'
Executing '/opt/share/unbound/configs/unbound.postconf'
/opt/var/lib/unbound/unbound.conf:202: error: cannot open include file '/opt/share/unbound/configs/unbound.conf.addgui': No such file or directory
read /opt/var/lib/unbound/unbound.conf failed: 1 errors in configuration file
Restarting dnsmasq.....
Done.

        ***ERROR FATAL...ABORTing!

OK - redid this and absolutely deleted every reference to unbound - all postconf files AND .conf.add files and anything else i could find with a reference to unbound and this time the install from single command line worked perfectly.
 
Last edited:
Had to reinstall unbound from scratch - seems to be calling a non existent file unbound.conf.addgui during install and then aborting. This is after a clean install from scratch after manually deleting all entries and directories relating to unbound. This should be easily repeatable for anyone installing Unbound from scratch. This was done using the single line install from Github.

Code:
Adding 'include: "/opt/share/unbound/configs/unbound.conf.addgui"  '/opt/var/lib/unbound/unbound.conf'
Adding 'include: "/opt/share/unbound/configs/unbound.conf.add"  '/opt/var/lib/unbound/unbound.conf'
Executing '/opt/share/unbound/configs/unbound.postconf'
/opt/var/lib/unbound/unbound.conf:202: error: cannot open include file '/opt/share/unbound/configs/unbound.conf.addgui': No such file or directory
read /opt/var/lib/unbound/unbound.conf failed: 1 errors in configuration file
Restarting dnsmasq.....
Done.

        ***ERROR FATAL...ABORTing!

OK - redid this and absolutely deleted every reference to unbound - all postconf files AND .conf.add files and anything else i could find with a reference to unbound and this time the install from single command line worked perfectly.
Whoops :oops: - thought I had already provided a Hotfix but clearly the hotfix was only 50% effective.:rolleyes:
v3.08 (already on GitHub dev branch) contains the correct patch so I might formally release it later today.
 
To make it short, may I kindly request that you change the 'dumb' part of the statement to something else? i.e. 'sneaky' or other suitable adjective of your choice... After all 'dumb' as they are they don't always do what we request them to do :).
Actually I doubt they are truly 'sneaky', as they dumbly (aka silently) obediently execute the request no matter how dumb the request is even if the result will never match the actual desired intended outcome. :p
 
A logging gremlin reappeared after the latest update; logging has always been turned off but a restart of the router or unbound itself causes logging to start up again.

Attached screenshot; logging is turned off. I restart unbound with "rs nocache" and logging reenables.

The last time this occurred in my setup, I had to do a fresh install. Everything was fine until this latest update. Have I missed something? Conf file shows logging disabled if I'm reading it right.. o_O

UB.jpg
 
A logging gremlin reappeared after the latest update; logging has always been turned off but a restart of the router or unbound itself causes logging to start up again.

Attached screenshot; logging is turned off. I restart unbound with "rs nocache" and logging reenables.

The last time this occurred in my setup, I had to do a fresh install. Everything was fine until this latest update. Have I missed something? Conf file shows logging disabled if I'm reading it right.. o_O

View attachment 23122
Would you mind doing a bit of debugging if you have the time?

Apply hack for pending unbound_manager v3.08 formal Fix
Code:
touch /opt/share/unbound/configs/unbound.conf.addgui


Now debug the logging status
Code:
unbound-control get_option verbosity;grep -E "^[#]*verbosity" /opt/var/lib/unbound/unbound.conf
then turn off logging without using the script
Code:
unbound-control set_option verbosity 0

unbound-control get_option verbosity;grep -E "^[#]*verbosity" /opt/var/lib/unbound/unbound.conf

unbound-control status
then restart unbound
Code:
A:Option ==> rs

unbound-checkconf: no errors in /opt/var/lib/unbound/unbound.conf

Removing 'include: "/opt/share/unbound/configs/unbound.conf.add"  '/opt/var/lib/unbound/unbound.conf'
Adding 'include: "/opt/share/unbound/configs/unbound.conf.addgui"  '/opt/var/lib/unbound/unbound.conf'
Adding 'include: "/opt/share/unbound/configs/unbound.conf.add"  '/opt/var/lib/unbound/unbound.conf'
 
Shutting down unbound...              done.
 Starting unbound...              done.

Checking status, please wait.....

 unbound cache RESTORED from '/opt/share/unbound/configs/cache.txt' (2020-04-29 11:46:28)

unbound OK
and check again
Code:
unbound-control get_option verbosity;grep -E "^[#]*verbosity" /opt/var/lib/unbound/unbound.conf
 
Last edited:
Would you mind doing a bit of debugging if you have the time?

Apply hack for pending unbound_manager v3.08 formal Fix
Code:
touch /opt/share/unbound/configs/unbound.conf.addgui


Now debug the logging status
Code:
unbound-control get_option verbosity;grep -E "^[#]*verbosity" /opt/var/lib/unbound/unbound.conf
then turn off logging without using the script
Code:
unbound-control set_option verbosity 0
then restart unbound
Code:
A:Option ==> rs

unbound-checkconf: no errors in /opt/var/lib/unbound/unbound.conf

Removing 'include: "/opt/share/unbound/configs/unbound.conf.add"  '/opt/var/lib/unbound/unbound.conf'
Adding 'include: "/opt/share/unbound/configs/unbound.conf.addgui"  '/opt/var/lib/unbound/unbound.conf'
Adding 'include: "/opt/share/unbound/configs/unbound.conf.add"  '/opt/var/lib/unbound/unbound.conf'
 
Shutting down unbound...              done.
 Starting unbound...              done.

Checking status, please wait.....

 unbound cache RESTORED from '/opt/share/unbound/configs/cache.txt' (2020-04-29 11:46:28)

unbound OK
and check again
Code:
unbound-control get_option verbosity;grep -E "^[#]*verbosity" /opt/var/lib/unbound/unbound.conf

The last command gives this
verbosity: 1 # v1.02 '1' is adequate to prove unbound is processing domains
 
Thank you for the assistance. :)

Just tried all the steps, final command results in;

Code:
#verbosity: 1                               # v1.02 '1' is adequate to prove unbound is processing domains
 
The last command gives this
verbosity: 1 # v1.02 '1' is adequate to prove unbound is processing domains
OK,
I have updated the diagnostic commands, there are now four.

Can you please repeat the diagnostics, but there is no need to restart unbound.
 
Thank you for the assistance. :)

Just tried all the steps, final command results in;

Code:
#verbosity: 1                               # v1.02 '1' is adequate to prove unbound is processing domains
There should be two lines of output? :confused:
 
Thank you for the assistance. :)

Just tried all the steps, final command results in;

Code:
#verbosity: 1                               # v1.02 '1' is adequate to prove unbound is processing domains

see this post#
 
Not what I got? Weird?
Do you not see TWO LINES reported, .....FIRST one containing a single digit and the SECOND LINE containing the statement from the file?:rolleyes::rolleyes::rolleyes::rolleyes:

e.g.
Code:
0
#verbosity: 1                               # v1.02 '1' is adequate to prove unbound is processing domains
Conf file shows verbosity at 1 too.

View attachment 23125
Yes but the '#' character at the start of the directive, means during the unbound initialisation, it should ignore setting 'verbosity: 1'

Now would you mind repeating the diagnostics one last time, and this time please include the additional diagnostic status command.
 
Do you not see TWO LINES reported, .....FIRST one containing a single digit and the SECOND LINE containing the statement from the file?:rolleyes::rolleyes::rolleyes::rolleyes:

e.g.
Code:
0
#verbosity: 1                               # v1.02 '1' is adequate to prove unbound is processing domains


.


Yup, that's exactly what I saw, apologies for missing that.


Tried again.

1.jpg

Also tried a restart immediately after those instructions;

2.jpg


Apologies if I'm not following your instructions exactly, am trying my best. Your help is sincerely appreciated! :)
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top