PiHole: Allow automatic update to specific version

As far as I can see there is no chance to run pihole -up and force it to use a specific version of the bundle. From screening the code that should not be a big deal to implement as the updating system works with git tags. So passing a valid tag to to the command like so pihole -up --target-version=vxyz should do the trick if the update script accepts the input. Is this somehow feasable to implement?

Update: yubiuser : It seems that I cannot reply to this topic after you moved it. Is this intention? So for now I use the edit function to reply to your question

Why do I think it is important to update to a specific version:
For stable environments it is crucial to pin versions of software packages installed. This is true for fresh installations but a bit more true for upgrade paths. And pihole is most often just a part in the whole infrastructure.

First reason: Beeing deterministic. Especially when using automation framework like Ansible it is very convienent to control which version of what gets installed in what manner.

Second reason: Being able to choose: Is there a release that introduced an unresolved issue that you don't want to bring into your infrastructure right now? But between your installed release and the latest is a another that is acceptable? Or you have issues when upgrading to a new major release but want the latest version within the current major release.

From my understanding pihole -up updates all three components of pihole. Therefore there might be the need to pin a pihole installation as a whole. E.g. pihole version tag "vX.Y" means shellscripts in version "vX.Y", DNS engine "vX.Y" and webserver "vX.Y".

I moved this to feature request.

Why do you want to upgrade to a specific version instead of the latest version?

Pi-hole consists of 3 parts, the DNS engine, the web interface and a collection of shell scripts. There are intereworkings in place and the components depend on each other.
Using out-of-sync versions can cause issues.

Feature Requests require a bit of time and effort on the submitter before they are allowed. This is to keep the noise down from people that come in to post a FR without doing any research or reading topics to see if their FR has been addressed before or if there are other open FRs for the same subject. If you had tried to open an FR in the FR area you would have been provided with this information and explanation.

I've upgraded your account to Trust Level 1 so you should be able to reply here.

2 Likes

Easiest way to do that is to use GitHub - pi-hole/docker-pi-hole: Pi-hole in a docker container

1 Like

That's a possible solution. Unfortunately I am (and maybe other folks too) using PiHole and many other services in a LXC container instead of docker for reasons I don't want to discuss here. So still, from my point of view there is a need to allow upgrades to specific versions :slight_smile: Do you think it is a lot of effort?

Yes. It's not so much the technically implementation of having pihole -up --target (basically this already exist) but having the whole infrastructure setup in a way that a single command specifies specific versions across three repos (components).

Yes.

We can't just allow for an arbitrary target to install. If you install per-component then we need to create a structure to know what component versions work with what other component versions and then block updating if there's an incompatible request.

If we create a single target then we have to do the exact same thing to determine what each single target is valid.

There's almost never a reason to not run the latest code and we really don't support previous versions, our default response is going to be "Update to the latest version and see if the problem still exists."

Or, as noted by others, use Docker. Pick the tool that does the job you want, not alter the job to fit the tool you are using.

1 Like

Ok, I accept that it is more effort then I thought. Sorry for that.
But personally I do not accept that blanket answer that there are no good reasons for updating to specific versions. I mentioned a few and they are valid in practice. Searching this forum brings up examples for PiHole (How to install a specific Pi-Hole version · Issue #3435 · pi-hole/pi-hole · GitHub, How do I revert to a previous version of Pi-hole?). But it is ok. Let's say we have here a discussion state of disagreement :slight_smile: Then let's see if the community upvotes this feature, because that is what a public listet FR is for, isn't it? :wink:

Just a little addendum: Your philosophy is not congruent to for example the IaaC good practice you can read here:

" In production environments, you should [...] specify a target version to ensure that packages are installed to a planned and tested version."

Thanks, can't say I really care?

Edit:

We provide ways to do what you wish to accomplish. You have decided that you would like to do something that avoids using the tools and processes we provide. That's fine and that's up to you. I'm not going to delve in to a massive amount of work to placate a single request for something that is already possible using the tools we provide.

If you have a specific need for a specific pedagogy then you are able to do that as well. All of our code is open and available and you can tweak it to do whatever you feel is necessary.

I don't know if that was intention. But because of the undertone I read I really can't say that I feel understood and/or taken seriously here with my request. Could have imagened nicer ways to say what you wanne say. Sorry for steeling your time.

I can say the exact same thing. You made a request, we replied and stated rather clearly why things are the way they are and the difficulties that come with making your requested changes. We also stated that there are options to do what you are needing, you can't, for reasons "I don't want to discuss here".

Instead of leaving it alone and accepting my response you decided to come back in an attempt to shame me in to doing what you want, a rather manipulative move, and I responded with my unfiltered response, I really don't care what some other people think is their standard of good practices.

So far I don't see a groundswell of support for this request but it won't be closed or ignored.

1 Like

Ah ok, I see. There were misleading comments from my side as well. Okay. Like the quoted one when I said "I don't want to discuss here". There I wanted to save us from off-topic that explains why it is not a solution to switch to docker containers for my use case. I will have a look if I missed something in regards of the other suggestion that at the first look did not do the trick for me either.

And please believe me: When I cited the Ansible project I did not want to shame you. I wanted to give a reference to a rather big community that propagates using a "latest" versions for automatic deployments as a bad practice. So you don't think I'm a lonely weirdo :wink: Maybe I am the first and maybe last requester in regards of PiHole. But in a more general sense my request is not that uncommon. That's all I wanted to say.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.