-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Latest docker release (2022.04) breaks DNS resolution on buster-based host OS #1035
Comments
Are you passing in the correct timezone? environment:
TZ: 'America/Chicago' |
Yes, forgot to include that in the above post, updated to reflect as such |
I also don't see the env var for enabling DNSSEC:
|
Can you please generate a debug token? |
Unfortunately it won't let me generate a debug token, but this time there was some more interesting stuff in the logs than before |
It's enabled via the web interface, on the test containers without volumes I didn't bother enabling it to check because it didn't work without DNSSEC either |
Hmm, that shows that I've just checked the image on a Pi 4 and it starts right up for me. What was the output when you ran the stock RUN command? And you do need to set the envvar if you want to enable via the web interface. |
Can you also run with the follow envvar set? environment:
DNSMASQ_USER: "root" |
I'm not sure what I changed between posting this issue and now, but I'm getting a different repeating log now:
No change in logs or behavior with the DNSMASQ_USER variable set though |
Reran the stock run command, it gave identical results to the compose file |
And what is your |
|
You're on Buster but you have an ancient version of the docker server. Have you run And are you using Docker Swarm, it seems that server is a member of a swarm but the certs are way expired. |
Yes, however it was installed long enough ago that it didn't have the current repo in apt. Anyways, i've now updated to docker server 20.10.14 and the issue persists |
I suggest updating to the latest Raspberry OS. I am slightly confused that you said this is Ubuntu 20 but it's Raspbian. |
So it is, my bad, got some devices mixed up. |
Got the same issue on Ubuntu 20.04 amd64 |
I'm seeing this on Arch Linux amd64 as well.
It looks like a fix has been merged in just a few hours ago. |
Looks like you have a different issue. Try adding NET_ADMIN capability to your |
I had the same issue as @hummeltech and this fixed it thanks. Though my understanding was NET_ADMIN was only needed if you're using DHCP which I'm not, unless something has changed. This started happening after updating the pihole image today. |
Running into the same issue as @hummeltech – this is new with 2022.4; reverting to 2022.02.1 fixes it |
Try adding NET_ADMIN capability to your |
Adding:
to the docker-compose indeed works around the problem, although it would be nice to know why it's now needed. I then run into the same issue as the OP: sudo: unable to get time of day: Operation not permitted |
Yes, I'd also be interested in knowing what change is causing this failure, it had been working without having to add the Edit: |
The latest docker engine, 20.10.14, addressed a security issue that changed how linux process capabilities are passed via inheritance. That required us to change how we allow See the discussion at #1021 which also contains a link to the docker issue discussion. This is the security note: GHSA-2mm7-x5h6-5pvq |
Thank you @dschaper |
Sure! I am trying to see if we can do DHCP without NET_ADMIN but that's just an experiment at this point. |
I'm having the same issue with Podman, unfortunately adding the NET_ADMIN capability doesn't help. Tried also with "dev", the errors are the same in latest (version.sh lines 23 and 127).
|
@jorgeml , try SYS_NICE, too. https://github.com/pi-hole/docker-pi-hole#note-on-capabilities It seems, at the moment, that the caps are required due to the way that dockers systems now work. Annoying, but we are doing the best we can with the information we have right now |
Same Issue with docker synology in DMS 7 update 3. Resolved adding the capability NET_ADMIN. |
@PromoFaux I am running Synology DSM7 Docker version 20.10.3-1239. The container is running with elevated privileges. Watchtower updated to the 2022.04.2 and then it started happening. Using the DNSMASQ_USER = root trick doesn't do anything. Only thing that works is going back to 2022.04 (probably .1 would also work but I didn't want to check). I can provide all the info you need :) |
Hi @DragonQ,
please, give this summary a read. HTH, |
Thanks, this allows both latest pihole and latest unbound docker containers to work on buster. I do plan to upgrade to bullseye eventually, I just don't want to break my HDMI cusomisations since I also use the Pi as my music player. |
@PromoFaux Could you confirm if this version fixes the
|
Same issue for me here:
DietPi Version: 8.3 image: pihole/pihole:dev
|
The answer you seek is in the link above: https://github.com/pi-hole/docker-pi-hole#upgrade-notes
|
Actually I can't update to bullseye now. Will give it a try in the next days. |
There is a bit more in the link, too, if you can't yet update to bullseye, but I left it out. @MichaIng - Do you have an official recommendation for updating |
It's the same as in Raspbian resp Debian. I suggest to report this to Debian, respectively to Raspbian (in case it is Raspbian/ARMv6 specific): |
Just adding briefly to the discussion here. I launch my container using docker-compose and ran into the same issue. One line which had been in my docker-compose file which was clearly causing an issue was this |
Just noting that this issue is linked to #1042 (which is another symptom). There are a few workarounds in that other issue. |
Sorry, I should have been more descriptive. I updated my DietPi OS (NOT my dockeer container of Pihole) about 4 weeks ago, before this release came out. Bam, killed my PiHole docker, it just wasn't working anymore. I have no idea if this latest docker release works but dietpi has made changes in the latest update which killed my pihole. I might upgrade both in a row? See if it combined it's ok. |
The DietPi update itself does not touch installed software, but the APT package upgrades may do. You can verify this by running journalctl -u docker and the individual container logs below And, as I suggested above, we should report this either to Debian/Raspbian, or to Docker. I mean the Docker repository has an explicit Buster suite, so one should expect that this suite ships Docker packages which are compatible with the library versions shipped by Buster: https://github.com/docker/docker-ce-packaging I'll also run some tests after Easter holidays on different Buster systems. |
This did it for me. |
@dschaper said:
I've fixed this issue by applying #1043 (comment) now. However, I gotta say that this statement is a bit discouraging. My main use-case for pi-hole in docker is that it creates a simple no-hands-on-needed way to continuously get updates to pi-hole. The tags Thanks for all your work! |
I would love to see a stable tag as mentioned above. I run this in docker as well with watchtower. So having a stable build would really help. |
:latest: is supposed to be stable. Occasionally things go wrong (we are only human) and we work on fixes. In the mean time you have the option to use the previous tag. The idea behind not using Ultimately, you can do what you want, but you really shouldn't be using watchtower to keep Pi-hole up to date. There are some notes in the readme about that. We don't provide/support an automatic upgrade path in a bare metal install - and Docker is no different. Things can go wrong, and you don't want that to happen and automatically take out your network when you're not in a position to remedy it. |
LATEST usually is stable.
All these versions worked correctly for most users, but due to specific combinations (operating system version + docker version + using or not using SSL + custom configurations) resulted in problems for a few other users, when they upgraded. Manual upgrades will avoid unexpected problems. |
@rdwebdesign sure. I'm not saying that the behaviour of the :latest: tag needs to change. But given all that you say, including that the latest tag caused a few problems for upgraders, and those problems were fairly soon fixed, how about having a :stable: tag that followed :latest: minor version with a delay of a month or two? By that time a fair amount of people will have tried :latest: and most serious bugs will have been found and fixed for that version. with one month delay: See how this method would have skipped the first LATEST versions, like 2021.12 and 2022.01 , so that people on STABLE would have had a smoother ride? I think this method could be a reasonable compromise between having automatically updated versions and having a pretty stable environment. |
This is a perfect example. We didn't release images without testing. We are run by volunteers and we have very limited resources. We do our best, but sometimes we miss a few issues. |
A perfect example of what? I was illustrating that this simple method would strike a balance between having reasonably new version and more stable than latest. The stable tag got one "unstable" version 2021.11, but skipped two 2021.12 and 2022.01. So it would have been more stable than latest. |
Those that make this product available, please know that the community as whole truly appreciates the effort you guys put in to make pi-hole great. |
I agree with this, the hard work is very much appreciated. Is there a way we can find a middle ground, is it possible to change the status of a release months after release? So you release a latest, if no complaints for 2 months, it becomes :stable? Is that viable, I'm not cluey enough software wise to know if this is viable. |
It's not as simple as that. If a critical security issue is found you do not want to wait a month to release it to STABLE. But nonetheless it's an option that is worth considering in my opinion. |
I don't think the middle ground really exists. The version of the docker container doesn't really follow semantic versioning, mainly because it is made up of the three main Pi-hole components - each with their own semantic version. We mentioned this in the release notes for 2021.09 The container's version number is derived from the date. If we release it on May 31st 2022, then the version number will be Bring that above scenario forward a few days, where we release on May 21st 2022, giving it a version number of What I'm trying to get at is that the To reiterate what is stated above - we can only try to release as stable a product as we can. We cannot test all scenarios and configurations that users may be using out in the field, and it would not be reasonable to expect us to :) (Not saying anyone is) To further reiterate our advice/position on automatic upgrades: "Don't do them, things can go wrong - and then you've taken out your whole network". Subscribe to the release feed, or monitor our blog, or discourse forum - read the release notes, take them in, and decide if you want to upgrade. If the answer is "yes", set aside some time to perform that upgrade. With all being well, it will be an uneventful process, but in case of something going wrong - you will be able to quickly revert to the previous version. In an ideal world, you would also first take a backup of your volume mounts before doing so. Very occasionally we release changes that make non-backward compatible alterations to the databases, in those cases - if you need to roll back, you'll need a copy of the database in it's previous state (lest you start again from scratch). Hell, there may even be scenarios where an upgrade requires the user to manually change something before/during the process (incredibly rare, but not impossible). The same advice applies to those that use Pi-hole on a bare metal install. If, after all that, you still want to use watchtower to keep your Pi-hole container up to date - then fine, we cannot actually stop you :). It's your system, you are free to do with it what you will! But we can only hold so many hands. All we can do is advise not to, and state our reasons why. |
This is a: Bug
The latest docker image does not correctly resolve queries. The Query log spits out errors for DNSSEC entries of
BOGUS (DNSSEC signature expired)
andBOGUS (DNSSEC sig not yet valid)
. This is correlated by the log spitting out these two lines on a loop:Reverting to version 2022.02.1 fixes the issue.
Related Issues
How to reproduce the issue
These common fixes didn't work for my issue
docker run
example(s) in the readme (removing any customizations I added)If the above debugging / fixes revealed any new information note it here.
Add any other debugging steps you've taken or theories on root cause that may help.
The text was updated successfully, but these errors were encountered: