PiHole v6 Upgrade should not assume 8080/8443 as "backup ports" for v6 webserver if port 80/443 is in use

Feature Requests
1

The piHole v6 upgrade process should not just assume port 8080/8443 for the new v6 webserver if the user chooses not to remove lighttpd during the upgrade.

The user should be prompted for the port number because docker containers commonly consume 8080/8443, etc. Multiple containers even get assigned 8081/8444 8082/8445, etc, so assuming any port is a bad idea.

At the very least, test if 8080 is already being used, and if so, prompt the user; otherwise, move forward with the automated upgrade.

For example:
bash: lsof -i:8080

THANKS!!

2

Actually this is just an attempt to help users.

Pi-hole v5 (just like many other software and the containers you use) simply defined a port without asking. It never tried to identify if a port was in use and it was user responsibility to define the port.

Pi-hole v6 is just trying to automatically find an alternative if port 80 is already occupied.
If port 8080 is also in use, it is user job to define the web server ports.

1 Like
3

In a fresh install, I would 100% agree. Still, this is a different case entirely since this was an upgrade initiated via the standard pihole -up command [honestly, when I ran the command, I had no idea this would be a major version upgrade].

You're already prompting the user if they want to keep their existing lighttpd install/settings, so I don't think it would be asking too much of you or the users to have to do an additional prompt [you can even let the default reply be 8080/8443], but allow the user to set the port during the upgrade.

I'm not saying I wasn't responsible for not doing my due diligence when I ran the upgrade command, but since I've only ever done minor version upgrades, I thought nothing of this being just a quick install and restart of the server.

Instead, because of an issue I ran into where I had duplicate IP lease entries configured in /etc/dnsmasq.d/04-pihole-static-dhcp.conf [and previous versions of pi-hole/dnsmasq never complained], after the upgrade, when pihole restarted, there was now a CRIT error that prevented dnsmasq from actually starting. Thus, I had no DNS resolution happening.

After the upgrade, I found that my entire network was down, and I couldn't access the web interface (because 8080 was already in use). Because my network was down, I panicked (until I remembered my phone) because I couldn't determine where to modify the port numbers for the new web server [pihole.toml].

Again, I could have done things differently to limit my risks, so I'm not saying I'm blameless, but it became a two-fold problem for me.

If you don't want to do this as a prompt, maybe add some text about where the port number is set in this new version in case, like me, they lose network access as a result of the upgrade.

THANKS!

4

If that's still too much to ask, then maybe, in the future, when there's a major version upgrade, add a prompt to pihole -up informing the user this is a major version upgrade, thus allowing them to stop the upgrade, so they can go an look at the notes, etc.

Yes, I should have done that myself, but assume all users are idiots. :wink:

2 Likes
5

ALSO, I don't want it to seem like I'm only complaining. After spending the night with it, I'm really impressed with all the v6 changes I've discovered so far!

EXCELLENT WORK!!!

1 Like
6

I always assume users haven't read the release notes, even if they say they have, and even if I'm sat behind them watching them read them :wink:

But noted on maybe adding a chance to back out of a running pihole -up session before committing anything to disk.

The difficulty here, though, is that any new logic added to the update script is pulled by the initial update script.. so in order to get the new update message one needs to update.... starts to get a bit recursive!

Personally I've been using the docker image for the last few years - I'm least likely to get bitten by any surprises in newer versions, but at least if I do it is trivial to roll back to a previous known-working image.

I'd love to be able to do something similar for bare metal, but it's a bit more complex. Maybe by the time 7.0 or 8.0 rolls around...

1 Like
7

I think doing a point release of the previous version with a release note of "Prepare for next major release" would work. For example, we do a v5.x+1.0 release that changes pihole -up with a note that says the next release is a major breaking change.

-Or-

We have code in the update process that does the major changes like database migration or config file migration that says "This process will bite you in the butt, you sure you want to do this?" and require a warm body response before proceeding.

2 Likes
8

Think we're on the same page, though this needs to be saved for major version updates, otherwise it just becomes noise. And please please please, include the URL to the release notes as part of that message. That way, it's a quick and easy way to review them.

Though, I really do want to push one last time for a prompt of the user for the port numbers to use if port 80/443 is in use. Just a simple prompt that assumes a default:

Web Server ports: [8080/8443]?

Anyone that doesn't know what that means would just hit enter, and anyone that does know what it means would know what to put in it's place.

THANKS!!!

1 Like
10

I second all Zac’s ideas - my network also broke and had to set my dns to googles as a temp measure while I nuked the pi holes vm’s and re setup everything I’m still convinced the update didn’t work though

It’s all working as it should now thankfully and is a cool update with lots of new features but when V7 eventually comes out I’m defo doing snapshots instead of assuming it’ll be fine xD

A built-in roll back option would be cool but might not be doable