Skip to content
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

Closed
6 tasks done
Willsr71 opened this issue Apr 1, 2022 · 81 comments
Closed
6 tasks done

Comments

@Willsr71
Copy link

Willsr71 commented Apr 1, 2022

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) and BOGUS (DNSSEC sig not yet valid). This is correlated by the log spitting out these two lines on a loop:

sudo: error initializing audit plugin sudoers_audit
sudo: unable to get time of day: Operation not permitted

Reverting to version 2022.02.1 fixes the issue.

Related Issues

  • I have searched this repository/Pi-hole forums for existing issues and pull requests that look similar

How to reproduce the issue

  1. Environment data
  • Operating System: Ubuntu 20.04
  • Hardware: Raspberry Pi 4b+
  • Kernel Architecture: armv7
  • Docker Install Info and version:
    • Software source: official docker
    • Supplimentary Software: none
  • Hardware architecture: x86_64
  1. docker-compose.yml contents, docker run shell command, or paste a screenshot of any UI based configuration of containers here
    pihole:
        image: pihole/pihole:2022.01.1
        #build: "./images/pihole-speedtest"
        hostname: "pihole"
        ports:
            - "53:53"
            - "53:53/udp"
            - "67:67/udp"
            - "80:80"
            - "443:443"
        volumes:
            - /home/pi/pihole/config:/etc/pihole
            - /home/pi/pihole/dnsmasq:/etc/dnsmasq.d
        cap_add:
            - NET_ADMIN
        dns:
            - 127.0.0.1
            - 1.1.1.1
        restart: "always"
        environment:
            TZ: "America/New_York"

These common fixes didn't work for my issue

  • I have tried removing/destroying my container, and re-creating a new container
  • I have tried fresh volume data by backing up and moving/removing the old volume data
  • I have tried running the stock docker run example(s) in the readme (removing any customizations I added)
  • I have tried a newer or older version of Docker Pi-hole (depending what version the issue started in for me)
  • I have tried running without my volume data mounts to eliminate volumes as the cause

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.

@dschaper
Copy link
Member

dschaper commented Apr 1, 2022

Are you passing in the correct timezone?

    environment:
      TZ: 'America/Chicago'

@Willsr71
Copy link
Author

Willsr71 commented Apr 1, 2022

Yes, forgot to include that in the above post, updated to reflect as such

@dschaper
Copy link
Member

dschaper commented Apr 1, 2022

I also don't see the env var for enabling DNSSEC:

environment:
  DNSSEC:  "true"

@rdwebdesign
Copy link
Member

Can you please generate a debug token?

@Willsr71
Copy link
Author

Willsr71 commented Apr 1, 2022

Unfortunately it won't let me generate a debug token, but this time there was some more interesting stuff in the logs than before
https://pastebin.com/wm6qfwab

@Willsr71
Copy link
Author

Willsr71 commented Apr 2, 2022

I also don't see the env var for enabling DNSSEC:

environment:
  DNSSEC:  "true"

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

@dschaper
Copy link
Member

dschaper commented Apr 2, 2022

Hmm, that shows that pihole-FTL never even started. I'm wondering how there were DNSSEC bogus messages displayed when it wasn't running. Something is very strange, the tag is correct.

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.

@dschaper
Copy link
Member

dschaper commented Apr 2, 2022

Can you also run with the follow envvar set?

environment:
  DNSMASQ_USER: "root"

@Willsr71
Copy link
Author

Willsr71 commented Apr 2, 2022

I'm not sure what I changed between posting this issue and now, but I'm getting a different repeating log now:

Starting pihole-FTL (no-daemon) as pihole
Unable to set inheritable capabilities: Operation not permitted
Stopping pihole-FTL
pihole-FTL: no process found

No change in logs or behavior with the DNSMASQ_USER variable set though

@Willsr71
Copy link
Author

Willsr71 commented Apr 2, 2022

Reran the stock run command, it gave identical results to the compose file

@dschaper
Copy link
Member

dschaper commented Apr 2, 2022

And what is your docker info output?

@Willsr71
Copy link
Author

Willsr71 commented Apr 2, 2022

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.6.3-docker)

Server:
 Containers: 12
  Running: 11
  Paused: 0
  Stopped: 1
 Images: 31
 Server Version: 19.03.12
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: error
  NodeID:
  Error: error while loading TLS certificate in /var/lib/docker/swarm/certificates/swarm-node.crt: certificate (1 - 6aeifnxmmmgchszn468xynfwl) not valid after Sat, 01 Aug 2020 00:02:00 UTC, and it is currently Fri, 18 Mar 2022 16:12:48 GMT: x509: certificate has expired or is not yet valid
  Is Manager: false
  Node Address: 192.168.1.3
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 5b46e404f6b9f661a205e28d59c982d3634148f8
 runc version: v1.0.2-0-g52b36a2
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.10.63-v7l+
 Operating System: Raspbian GNU/Linux 10 (buster)
 OSType: linux
 Architecture: armv7l
 CPUs: 4
 Total Memory: 3.749GiB
 Name: pi4-1
 ID: WGQU:TPIC:5UM4:RYJ7:OQSZ:4Q6S:XIL6:5WSD:W6PS:Y5FT:BMKK:K43H
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No kernel memory TCP limit support
WARNING: No oom kill disable support

@dschaper
Copy link
Member

dschaper commented Apr 2, 2022

You're on Buster but you have an ancient version of the docker server. Have you run apt update and apt upgrade recently?

And are you using Docker Swarm, it seems that server is a member of a swarm but the certs are way expired.

@Willsr71
Copy link
Author

Willsr71 commented Apr 2, 2022

Yes, however it was installed long enough ago that it didn't have the current repo in apt.
I did notice it's still apparently a member of the swarm, it hasn't been in use as such since before the certs expired.

Anyways, i've now updated to docker server 20.10.14 and the issue persists

@dschaper
Copy link
Member

dschaper commented Apr 2, 2022

I suggest updating to the latest Raspberry OS.

I am slightly confused that you said this is Ubuntu 20 but it's Raspbian.

@Willsr71
Copy link
Author

Willsr71 commented Apr 2, 2022

So it is, my bad, got some devices mixed up.

@pataar
Copy link

pataar commented Apr 2, 2022

Got the same issue on Ubuntu 20.04 amd64

@hummeltech
Copy link

I'm seeing this on Arch Linux amd64 as well.

pi_hole  |  ::: Docker start setup complete
pi_hole  |   Checking if custom gravity.db is set in /etc/pihole/pihole-FTL.conf
pi_hole  |   Pi-hole version is v5.9.1 (Latest: v5.9.1)
pi_hole  |   AdminLTE version is v5.11 (Latest: v5.11)
pi_hole  | /opt/pihole/version.sh: line 23: /usr/bin/pihole-FTL: Operation not permitted
pi_hole  | /opt/pihole/version.sh: line 127: /usr/bin/pihole-FTL: Operation not permitted
pi_hole  |   Latest FTL version is v5.14
pi_hole  |   Container tag is: 2022.04

It looks like a fix has been merged in just a few hours ago.
pi-hole/pi-hole#4665

@rdwebdesign
Copy link
Member

@hummeltech

Looks like you have a different issue.

Try adding NET_ADMIN capability to your docker-compose file or docker run command.

@kgillibrand
Copy link

kgillibrand commented Apr 2, 2022

@hummeltech

Looks like you have a different issue.

Try adding NET_ADMIN capability to your docker-compose file or docker run command.

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.

@patricegautier
Copy link

patricegautier commented Apr 2, 2022

Running into the same issue as @hummeltech – this is new with 2022.4; reverting to 2022.02.1 fixes it

@rdwebdesign
Copy link
Member

Try adding NET_ADMIN capability to your docker-compose file or docker run command.

@patricegautier
Copy link

Adding:

cap_add:
  - NET_ADMIN

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

@hummeltech
Copy link

hummeltech commented Apr 2, 2022

Yes, I'd also be interested in knowing what change is causing this failure, it had been working without having to add the CAP_NET_ADMIN Linux capability on previous versions for the past year or so. I must have mistakenly assumed that the change I referenced had fixed the issue.

Edit:
I'm not using DHCP either.

@dschaper
Copy link
Member

dschaper commented Apr 2, 2022

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 pihole-FTL to use it's capabilities and there is no conditional way to use some caps in some cases and other caps in other cases.

See the discussion at #1021 which also contains a link to the docker issue discussion. This is the security note: GHSA-2mm7-x5h6-5pvq

@patricegautier
Copy link

Thank you @dschaper

@dschaper
Copy link
Member

dschaper commented Apr 2, 2022

Sure! I am trying to see if we can do DHCP without NET_ADMIN but that's just an experiment at this point.

@jorgeml
Copy link

jorgeml commented Apr 2, 2022

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).

# podman container run -it --rm --cap-add NET_ADMIN pihole/pihole:dev
Resolved "pihole/pihole" as an alias (/var/cache/containers/short-name-aliases.conf)
Trying to pull docker.io/pihole/pihole:dev...
Getting image source signatures
Copying blob 4f4fb700ef54 skipped: already exists  
Copying blob 8d64124103fd skipped: already exists  
Copying blob 32252aec0777 skipped: already exists  
Copying blob 201ecda89dc8 done  
Copying blob 935ee8087956 done  
Copying blob 4bc282838b60 done  
Copying blob 22b249974ab3 done  
Copying blob 2e5ac72d671d done  
Copying blob 468565f48ac2 done  
Copying config f79abfa7eb done  
Writing manifest to image destination
Storing signatures
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] 01-resolver-resolv: applying... 
[fix-attrs.d] 01-resolver-resolv: exited 0.
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 05-changer-uid-gid.sh: executing... 
[cont-init.d] 05-changer-uid-gid.sh: exited 0.
[cont-init.d] 20-start.sh: executing... 
 ::: Starting docker specific checks & setup for docker pihole/pihole
Assigning random password: dzjn0wno

  [i] Installing configs from /etc/.pihole...
  [i] Existing dnsmasq.conf found... it is not a Pi-hole file, leaving alone!
  [✓] Installed /etc/dnsmasq.d/01-pihole.conf
  [✓] Installed /etc/dnsmasq.d/06-rfc6761.conf
/opt/pihole/updatecheck.sh: line 77: /usr/bin/pihole-FTL: Operation not permitted
/opt/pihole/updatecheck.sh: line 91: /usr/bin/pihole-FTL: Operation not permitted
Existing DNS servers detected in setupVars.conf. Leaving them alone
  [✓] New password set
DNSMasq binding to default interface: eth0
Added ENV to php:
			"TZ" => "",
			"PIHOLE_DOCKER_TAG" => "dev",
			"PHP_ERROR_LOG" => "/var/log/lighttpd/error.log",
			"ServerIP" => "0.0.0.0",
			"CORS_HOSTS" => "",
			"VIRTUAL_HOST" => "0.0.0.0",
Using IPv4 and IPv6
::: setup_blocklists now setting default blocklists up: 
::: TIP: Use a docker volume for /etc/pihole/adlists.list if you want to customize for first boot
::: Blocklists (/etc/pihole/adlists.list) now set to:
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
::: Testing lighttpd config: Syntax OK
::: All config checks passed, cleared for startup ...
::: Enabling Query Logging
  [i] Enabling logging...
  [✓] Restarting DNS server
  [✓] Logging has been enabled!
 ::: Docker start setup complete
  Checking if custom gravity.db is set in /etc/pihole/pihole-FTL.conf
  Pi-hole version is v5.9.1 (Latest: v5.9.1)
  AdminLTE version is v5.11 (Latest: v5.11)
/opt/pihole/version.sh: line 23: /usr/bin/pihole-FTL: Operation not permitted
/opt/pihole/version.sh: line 127: /usr/bin/pihole-FTL: Operation not permitted
  Latest FTL version is v5.14
  Container tag is: dev
[cont-init.d] 20-start.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
Starting lighttpd
Starting pihole-FTL (no-daemon) as pihole
Starting crond
[services.d] done.
Unable to set inheritable capabilities: Operation not permitted
Stopping pihole-FTL
pihole-FTL: no process found

@PromoFaux
Copy link
Member

@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

@jempo
Copy link

jempo commented Apr 2, 2022

Same Issue with docker synology in DMS 7 update 3. Resolved adding the capability NET_ADMIN.
Thanks @PromoFaux

@RhavoX
Copy link

RhavoX commented Apr 4, 2022

@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 :)

@scara
Copy link

scara commented Apr 4, 2022

Hi @DragonQ,

I get these errors on my Pi 4B running 2021-05-07-raspios-buster-armhf-lite using 2022.04.2beta:

sudo: unable to get time of day: Operation not permitted
sudo: error initializing audit plugin sudoers_audit

Buster has issues with Docker 20.10.14 and Bullseye based images.

please, give this summary a read.

HTH,
Matteo

@DragonQ
Copy link

DragonQ commented Apr 5, 2022

Hi @DragonQ,

I get these errors on my Pi 4B running 2021-05-07-raspios-buster-armhf-lite using 2022.04.2beta:

sudo: unable to get time of day: Operation not permitted
sudo: error initializing audit plugin sudoers_audit

Buster has issues with Docker 20.10.14 and Bullseye based images.

please, give this summary a read.

HTH, Matteo

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.

@chrisg991
Copy link

@PromoFaux Could you confirm if this version fixes the sudo: unable to get time of day: Operation not permitted error or the error initializing audit plugin sudoers_audit that OP was having, please? I'm getting the former.

I've just pushed a new dev build that should hopefully solve this issue once and for all. It only attempts to set capabilities if they are available to the container.

Please try the dev - for those of you that don't need NET_ADMIN, please also unset this when trying the newest dev

Thanks all for your continued patience!

@PromoFaux
Copy link
Member

@cc13com
Copy link

cc13com commented Apr 8, 2022

Same issue for me here:

sudo: unable to get time of day: Operation not permitted
sudo: error initializing audit plugin sudoers_audit

DietPi Version: 8.3

image: pihole/pihole:dev

lsb_release -a
No LSB modules are available.
Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

@PromoFaux
Copy link
Member

PromoFaux commented Apr 8, 2022

The answer you seek is in the link above: https://github.com/pi-hole/docker-pi-hole#upgrade-notes

  • You may run into issues running 2022.04 and later on buster-based host systems due to a known issue with Seccomp. The first recommendation is to upgrade your host OS to bullseye, which includes a more up to date (and fixed) version of libseccomp2.

@cc13com
Copy link

cc13com commented Apr 8, 2022

Actually I can't update to bullseye now. Will give it a try in the next days.

@PromoFaux
Copy link
Member

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 libseccomp2 to a newer version in dietPi 8.3? Or is it the same as it would be for raspbian, say?

@MichaIng
Copy link
Contributor

MichaIng commented Apr 8, 2022

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

@PromoFaux PromoFaux changed the title Latest docker release (2022.04) breaks DNS resolution on armv7 Latest docker release (2022.04) breaks DNS resolution on buster based host OS Apr 8, 2022
@PromoFaux PromoFaux changed the title Latest docker release (2022.04) breaks DNS resolution on buster based host OS Latest docker release (2022.04) breaks DNS resolution on buster-based host OS Apr 8, 2022
@modonovan
Copy link

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
privileged: true
this should be hashed/removed in order to overcome this issue. FWIW I already had NET_ADMIN and DNSMASQ_USER set but the fix for me was removing the now unnecessary line of privileged: true

@MayeulC
Copy link

MayeulC commented Apr 14, 2022

Just noting that this issue is linked to #1042 (which is another symptom). There are a few workarounds in that other issue.

@jaxjexjox
Copy link

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.
So I revered the OS (not the docker) and it kept working.

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.

@MichaIng
Copy link
Contributor

MichaIng commented Apr 15, 2022

The DietPi update itself does not touch installed software, but the APT package upgrades may do. You can verify this by running apt update && apt upgrade and see whether this breaks the container as well. Especially kernel upgrades may be responsible, recently most SBCs received a bump from Linux 5.10 to 5.15, and of course the latest Docker package release. If the container does not start, please check the service logs:

journalctl -u docker

and the individual container logs below /mnt/dietpi_userdata/docker_data. Compare this with the errors reported in comments above, indicating an incompatibility between latest Docker and libseccomp2 from Debian/Raspbian Buster. If so, here is a guide about how the system can be upgraded to Debian/Raspbian Bullseye: https://dietpi.com/blog/?p=811
Another workaround would be to downgrade Docker and set the packages on hold or pin them. I can give some instructions about how this can be done.

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.

@jckozy86
Copy link

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 privileged: true this should be hashed/removed in order to overcome this issue. FWIW I already had NET_ADMIN and DNSMASQ_USER set but the fix for me was removing the now unnecessary line of privileged: true

This did it for me.
I run pihole through QuNAP docker (container station) and I left the "run in privilige mode" checked off.

@Mellbourn
Copy link

Mellbourn commented May 9, 2022

@dschaper said:

Don't use latest it's a big risk.

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 nightly and dev are even more experimental than latest. If you really don't feel that we should trust latest, could you please create a stable tag or something similar that still allows for automatic but more conservative upgrades?

Thanks for all your work!

@k2gremlin
Copy link

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.

@PromoFaux
Copy link
Member

: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 latest is more about pinning to a specific version - and manually upgrading to newer versions when you are able to set aside some time to so so.

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.

@rdwebdesign
Copy link
Member

LATEST usually is stable.
It always points to the most recent version, but this is a "floating" label:

  • 6 months ago LATEST was 2021.11
  • 5 months ago LATEST became 2021.12 and 3 days later it was 2021.12.1
  • 4 months ago LATEST became 2022.01 and 2 days later 2022.01.1
  • 3 months ago LATEST was 2022.02.1
  • 1 month ago LATEST, in the period of 4 days it was 2022.04, 2022.04.1, 2022.04.2 (to fix docker issues).
  • 19 days ago it became 2022.04.3.

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.

@Mellbourn
Copy link

Mellbourn commented May 9, 2022

@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:
5 months ago STABLE would have been 2021.11
4 months ago STABLE would have been 2021.12.1
3 months ago STABLE would have been 2022.01.1
2 months ago STABLE would have been 2022.02.1
1 month ago STABLE would have been 2022.02.1

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.
Not automating updates is also a risk, since then you could miss important security updates if you get sloppy.

@rdwebdesign
Copy link
Member

This is a perfect example.

We didn't release images without testing.
2021.12 was tested, considered stable and then released, but after that an issue was found and we released 2021.12.1.
2021.12.1 was considered stable too.

We are run by volunteers and we have very limited resources. We do our best, but sometimes we miss a few issues.
Using a different name for the tag won't change our effort.

@Mellbourn
Copy link

Mellbourn commented May 9, 2022

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.

@k2gremlin
Copy link

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.

@jaxjexjox
Copy link

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.

@hubermi
Copy link

hubermi commented May 10, 2022

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.

@PromoFaux PromoFaux unpinned this issue May 10, 2022
@PromoFaux
Copy link
Member

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 2022.05. If we discover there is a bug with that version, and fix it on June 2nd 2022, then the version number will become 2022.06

Bring that above scenario forward a few days, where we release on May 21st 2022, giving it a version number of 2022.05, and then a bug fix on 25th May - the version becomes 2022.05.1 (the .1 indicating that it is the 1st revision in May (or 2nd image released in May))

What I'm trying to get at is that the .x after year.mo doesn't necessarily relate to anything meaningful - only that we have already cut one release that month, so we need a different version number. Manually tagging a previous release as recent-but-not-quite-latest adds an additional overhead, and something that would probably go forgotten - and how would we do it programmatically? What is there to say that a particular previous release is considered "without issues"? The issues aren't always apparent for all users. Sometimes things only affect a handful of users. What is "stable" for one, may not be for another.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests