PiVPN does not resolve with beta version of Pi-hole

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?

edit log-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.

This has now also been reported on GitHub.

Hey

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 :slight_smile:

@DanSchaper Maybe you can have a look because the commit was yours and so you can find a solution quite easily :slight_smile:

2 Likes

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.

Ah, okay, I see it now.

set -e

The bare return is tripping that and ends processing. I'll fix that with a guard like on pi-hole/basic-install.sh at 7bca585067eefe54f6f630a6ed269da22587b091 · pi-hole/pi-hole · GitHub

Edit:

See Guard for logrotate func non-zero return by dschaper · Pull Request #4242 · pi-hole/pi-hole · GitHub

1 Like

First of all, thanks for your commit, it's working.
Switched to master and back to be safe.
It's fine now.

Just got one error (repeatable) on updating:

[i] Installing latest Cron script
[i] Installing latest logrotate script...
[i] Existing logrotate file found. No changes made.
[✗] Failure in logrotate installation function.

But its not stopping and runs. Thank you :slight_smile:

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. :slight_smile:

Thanks for information, would be okay for me. :slight_smile:

I'm sysadmin , so I'm normally quite interested that every is 'info' or 'okay' instead of 'warn' or 'failure' :smiley:

1 Like

Well given we are on a beta branch, we tend to pay attention when updating. :wink:

I appreciate it!

1 Like

This issue should be fixed by now, can you confirm this?

2 Likes

I can confirm this is fixed.

1 Like

Yes it's working, it is not showing this line anymore.

2 Likes

I can also confirm that this is fixed.

1 Like