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.

3 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

11

I can't believe that is true. "If port 8080 is also in use, it is user job to define the web server ports." Well yeah after the network breaks because you rebooted your server 6 months after you uped the pihole. This is insane.

12

I agree. Not making this a prompt, with a default value even, seems like such a strange hill to die on. :man_shrugging: I had thought about going through the whole fork and pull request to change it, but I just get the vibe that after going through all that effort they still wouldn't pull it.

13

The upgrade informs you that it will try using port 8080 if you opt to keep lighttpd. That would only affect how you access Pi-hole's web UI.
It won't break Pi-hole's DNS functionality.

14

You are actually thinking that "The upgrade informs you" is a sufficient excuse for what's happening here? Again: This is insane. The update is a console process that goes up the window. Pihole hijacks this port. If don't pay really close attention this goes unnoticed. If you reboot your system nginx will fail if you had that port in use because now pihole will own and block it. Everything related to nginx on your system then is DOWN. As long as you get those calls from people panicing about having no access to xy and z.
This is insane. What am I raging about... ZacWolf already said everything.

15

Is there a reason why you are using the default console instead of an SSH client? How is your poor choice of accessing your device pi-hole's fault?

If you are running pi-hole in a prod environment not on something where you can revert from backups, that is again, not pi-hole's fault.

This is textbook blame-shifting instead of owning up to your mistakes and trying to do better.

1 Like
16

Youre making up stuff that is completely irrelevant and hallucinated btw. Blame-shifting yeah exactly. It is a crappy and completely stupid way of making use of a port that is so widely used. And yeah there are users out there tha are not godlike avartars as you probabaly are. Sorry I'm with Zac, just not as friendly as he is.

17

You're clearly trolling, so I'll end my discussion here.

If you cannot read the lines of text in a terminal during an update, stick to Windows. Plain and simple.

1 Like
18

No, I am saying that you were given a choice of disabling lightppd (and have Pi-hole use port 80) or keeping it (and Pi-hole trying to use port 8080).

Furthermore, the resulting URL intended to be used for accessing Pi-hole's web UI would have been shown at the end of the upgrade process - including the port.

While I agree that the choice could be presented in a more concise way, I don't think that constitutes hi-jacking.

ZacWolf suggests to allow customising the fallback port during installation, but that wouldn't add any information with regards to the choice to be made. And someone who hasn't paid attention to the current choice probably would still overlook yet another option.

I'm inclined to favour rdwebdesign's approach instead: Just log an error if the standard port is unavailable, and do not configure any webserver port at all.

19

I agree. And please let's not weigh semantics too much. i do think it "constitutes hi-jacking", theport was owned by someone else before pihole took over. But you can have a different opinion. We have all a lot to do. Don't assume everyone is doing a 100% by the rules job in updating pi-hole. Somehow in every community there are devs and other people thinking that ordinary users are involved like crazy in their product. That's not the case and that's of course the root of the their problem (if one occurs) and no-one else is to blame for that other than the user. So now it just comes down to how willing sofware developpers are taking this into account. Assuming the dumbest user ever and building a saftety net. Or just avoiding obviously precarious changes. It would have been easy here in this case. I am using pihole for many years, I am very happy with it, never had any problems, I never had the feeling that I had to pay too much attention because updates were rock solid. I usually do a backup and restore if things go south. But I'll stick to Windows now. Like he said, the plain and simple.

20

In my opinion, apparently we (Pi-hole developers) tend to develop thinking most users need too much assistance and this was the reason for creating this "automatic attempt" to use an alternative port.

Maybe suggesting an alternative port is just too much "hand-holding".

As I said in a previous team conversation, I don't think we need to increase the installer complexity adding a new prompt/step and maybe we just need to simplify the installer:

  • only try the default ports (80 and 443), like most web servers do.
  • if they are in use, don't start the web server and log an error message saying one or more ports are unavailable.

This is how most web server installers do.
We already do that for DNS port. If port 53 is in use by another service, Pi-hole DNS won't be available.

3 Likes
21

Spot on. Shift the "The upgrade informs you" policy away from "Bad things can happen if you don't act now" to "you need to check on this or that before pihole will work again". Imho it's much better to check on an immediate update failure than getting confronted with a broken network 6 months later, not knowing what caused the issue just because you were a bit sloppy during the update process where seemingly nothing went wrong.