Why port 443?

[Permanently]

Hiya, got Proxmox and I'm looking at clustering but I'm just trying to figure out why 443 is needed. I've not needed it thus far for my local cluster (hooking in a third external one via Tailscale). I didn't know if there was more information on why it's needed, and how it can be enabled if poss?

[willjasen]

TCP 443 isn't "needed", it was a design decision. Using tailscale serve --bg https+insecure://localhost:8006, it proxies both TCP 8006 and 443. More of a personal choice, but not having to include the port in the URL is just cleaner. But yes, with that decision, the script checks that TCP 443 is available because of it.

See also: https://tailscale.com/kb/1133/proxmox

[Permanently]

Ahhh, right - think that's where I've been confused. I'm using Headscale, so tailscale serve isn't a thing for me hence why I've had errors on 443 validation.

Just to clarify, it's completely fine to remove the 443 and serve functions from the script? I did it anyway, seems fine :) I do think though Headscale and custom co-ordination servers may need to be accommodated for in this, so at some point if it's not done before me I may do a PR to add manual confirmation of whether serve and port 443 should be rolled out by the script.

[willjasen]

The one problem that I can foresee (and why tailscale serve was added) is that of managing the certificates that Proxmox uses. Before, I was using https://github.com/willjasen/tailscale-cert-services to create a valid certificate via Tailscale and then binding that certificate to the "pveproxy" service in Proxmox, but was having to manage its renewal, which in theory was being handled 100% successfully via some custom scripts and a cron job. I found that it wasn't quite working all of the time, which is what led me to use tailscale serve instead. It handles renewing the certificate as needed and also decouples that from the bound Proxmox certificates themselves, in which services like "pveproxy" had to be restarted after any certificate renewals via the previous way of managing them (which thankfully isn't necessary when using serve).

Because of this and for your case, I would leave tailscale serve in, but make it not require TCP 443 necessarily. This should avoid any messy certificate issues down the road. The easiest way of doing this would be to remove the check, but that assumes that TCP 443 isn't being used by another process (which again, generally isn't an issue).

[willjasen]

Hey! I'm working on the dev branch, building out some things.

I went back and re-read and I dunno why I suggested leaving tailscale serve in - it's not there in Headscale (naturally).

I'm brainstorming a "headscale" option that wouldn't use tailscale serve, but the main problem I still foresee with that is the renewal of the Proxmox certificates for its web UI still needs to be handled, which would require tailmox to live in the background as a service. There will be a new feature called tailmox monitor that runs the tailmox test process and records the results into a SQLite database as well as serves a webpage to view that information. All of that is a read-only type of situation though - tailmox monitor doesn't ever make any changes to the cluster, and I don't want tailmox sitting in the background with the possibility that it changes things about the cluster - that should only happen interactively.

Still thinking - there's many parts to be moved around.

[willjasen]

My current thoughts on this is that I probably won't be spending too much time on a "headscale" style implementation for the time being.

tailmox on the dev branch has come a long way and heavily relies on tailscale serve and also uses tailscale services - for ease of use and manageability. For example, my Tailscale Services URL is https://tailmox.risk-mermaid.ts.net and it talks to any tailmox cluster member that is online.

The issue with the Proxmox cluster certificate would still exist, too.