I seem to have a slightly different configuration from @squawkingvfr and @bungh0l10 but the work-around is similar.
In setupVars.conf, I have "DNSMASQ_LISTENING=local" instead of "all" or "single" and in 01-pihole.conf, among other changes, the beta adds a new "interface=eth0" line.
I commented out "interface=eth0" and restarted dnsmasq. And voilà wireguard started resolving DNS again. I did try keeping the "interface=eth0" and adding "except-interface=nonexisting", but that didn't work either.
Here is 01-pihole.conf created by master:
addn-hosts=/etc/pihole/local.list
addn-hosts=/etc/pihole/custom.list
localise-queries
no-resolv
cache-size=10000
log-queries
log-facility=/var/log/pihole.log
local-ttl=2
server=127.0.0.1#5335
domain-needed
-expand-hosts
bogus-priv
-local-service
-server=/use-application-dns.net/
and created by beta:
addn-hosts=/etc/pihole/local.list
addn-hosts=/etc/pihole/custom.list
domain-needed
localise-queries
bogus-priv
no-resolv
server=127.0.0.1#5335
+interface=eth0
cache-size=10000
log-queries
log-facility=/var/log/pihole.log
local-ttl=2
+log-async
Thanks for the comparison. This is really confusing. The only intended change is
-server=/use-application-dns.net/
while the others
-expand-hosts
-local-service
+interface=eth0
should not happen (with the exception of the interface option they should all be there).
I looked again at the beta changes and nothing changes anything in the related code (except the mentioned server=/use-application-dns.net/ line). Maybe someone else can look at the changes with fresh eyes?
editlog-async was a false positive, removed my analysis for this one.
I accidentally deleted log-async from the master example when I was removing blank lines. It should have appeared in the location you show in the 01-pihole.conf template.
I will answer here to collect all information in one place.
I did some research maybe it could help.
Three situations:
(1)Master Branch
(2)Beta Branch (directly after Update)
(3)Beta Branch (after editing for workaround)
Files compared:
01-pihole.conf
SetupVars.conf
If I compare setupVars.conf from (1) and (2) they are exactly the same (No reordering)
If I compare setupVars.conf from (2) and (3) then the content is the same but they reordered. In (2) after BLOCKING_ENABLED there comes DNSMASQ_LISTENING. In (3) there comes PIHOLE_INTERFACE. So it seems like variables in setupVars.conf are reordered. All variables are in both Files but after the line BLOCKING_ENABLED in an different order.
Maybe this could be the reason that 01-pihole.conf from (1) and (2) differ so much (already mentioned local-service etc) but (1) and (3) looks likely the same (server=use... is added in (3))
Maybe this could help a little to find the problem
This is really puzzling because this is not what should be happening:
The only reason I can imagine is that DNSMASQ_LISTENING is not set because source ${setupVars} failed for some reason.
I've been affected by the recent flood in western Germany (Kreis Ahrweiler, you may or not have heard about it) so I haven't been able to spin up a proper testing box myself but we'll come to it, eventually! (TBH, I'm still hoping someone beats me to doing it myself)
I think I finally found the problematic line.
I was wondering why it would not working during Install or repair but If I change a setting over the GUI.
It uses a different script: webpage.sh vs. basic-install.sh
The "problematic" commit is the following:
This was introduced during beta / development.
If installlogrorate() is returning return 2 (that is every time the file logrorate is present), the following lines won't be executed:
And so - especially finalExports- will not write changes to setupVars.conf during install/repair.
Then I tried to comment out return 2 (so it would copy file and so on) then everything is fine!
Installer return 2 commented out:
...
[i] Installing latest logrotate script...
[i] Existing logrotate file found. No changes made.
[✓] Installing latest logrotate script
[i] Backing up /etc/dnsmasq.conf to /etc/dnsmasq.conf.old
[✓] man pages installed and database updated
[i] Testing if systemd-resolved is enabled
...
Installer without changes:
...
[i] Installing latest logrotate script...
[i] Existing logrotate file found. No changes made.
[i] Testing if systemd-resolved is enabled
...
(you see the missing dnsmasq and man pages lines)
I didn't commit it because it is a dirty workaround (checking for existing logrorate make sense) but maybe with this hint a working solution can be found
@DanSchaper Maybe you can have a look because the commit was yours and so you can find a solution quite easily
Thanks, I'm going to guess that calling a function inside of another function that is inside of yet another function is tripping something up. I'll take a look at it in the morning but that installLogrotate should be in main() and should have an installLogrotate || handle non-zero return guard on it. I thought it did, but maybe that was what I wrote on the lua proof of concept I was working on.
Sure, I guess that could be an Info instead of a Cross for failure. If you read the line directly above it then you will see why it called a "Failure" in the function.
Open to better wording if there are other thoughts.
As you said could be 'info' instead of 'failure-cross' - but it only make sense If you can differ between 'real failure' (then there should be cross) and 'info failure' ( in this case)
Right now the function really only has one return on it, and that's when there is an existing logrotate file. Bash is kind of difficult to discern different return values so it's probably easiest to just make it an info or just let it be silent and only include the line above about an existing logrotate file being there.
I'm surprised that people are catching that output, most just ignore it all.