mirror of
https://github.com/fosrl/pangolin.git
synced 2026-05-08 05:39:49 -05:00
[GH-ISSUE #1938] Invalid license key error #2047
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/pangolin#2047
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @kmanwar89 on GitHub (Nov 29, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1938
Describe the Bug
Per guidance under https://github.com/orgs/fosrl/discussions/1894#discussioncomment-15018258, I requested a license key from Pangolin's website and applied it to my self-hosted instance.
However, upon doing so, I'm now seeing the following error at the bottom of the login page:
When I check the license keys, it says they've been rechecked, and shows as not valid, but doesn't provide a reason why it isn't valid - it has a 10 year expiry, so what exactly is happening? Why was the license key allowed to be added if it was invalid from the beginning?
If I check the
licensekey on pangolin.net, it shows as valid - judging by the last few characters, it appears to be the identical key, which would make sense as I copied/pasted it directly.Deleting, and re-adding, the license key yields a "failed to fetch" error:
Pangolin is hosted on a VPS on RackNerd, so there shouldn't be restrictions on WAN access. If a specific firewall rule needs to be allowed, please let me know but I don't think I have anything restrictive setup as it stands today.
Environment
(I'm not certain how to retrieve the above versions)
To Reproduce
(I think these are the steps. It's not clear to me since I didn't start seeing the messages until a few days after applying the license to my server)
Expected Behavior
No error should be presented if the license key is valid, OR the license key should perform a check before applying, with a verbose error as to why it is invalid, and what steps the user should take to remediate it.
@oschwartz10612 commented on GitHub (Nov 29, 2025):
Hum we have seen this a couple of times. Are you able to curl https://api.fossorial.io/api/healthcheck from inside of the pangolin container?
docker exec -it pangolin curl https://api.fossorial.io/api/healthcheck?@kmanwar89 commented on GitHub (Nov 29, 2025):
Nice to hear from you Owen - I'm certain I keep you guys busy ;)
Looks like I cannot curl it from within the container:
FWIW, I'm not able to hit any other URL's either via DNS - google or similar, either with ping or curl, so this might be boiled down to a communication issue. What's not clear to me is I don't have anything configured (allow or deny) that would prevent it, I think. I've just been using the basic compose file from the website for months now with no issues.
Looks like other containers on the same VPS also can't resolve DNS, but they can ping out via IP just fine. Pangolin container pings out fine via IP, but fails DNS resolution.
@oschwartz10612 commented on GitHub (Nov 29, 2025):
Hum strange! What if you explicitly set the DNS on the container in
docker compose?
version: '3.8'
services:
my_service:
image: my_image
dns:
- 8.8.8.8 # Google Public DNS
- 8.8.4.4 # Google Public DNS
@kmanwar89 commented on GitHub (Nov 30, 2025):
Doing so seems to send the Crowdsec container into a bit of a fit:
Guessing I'd need to add it to each service within my file - I'm using a single compose file that contains Pangolin, Crowdsec, Traefik, and Gerbil.
@kmanwar89 commented on GitHub (Nov 30, 2025):
Confirmed: added the same entries to the Crowdsec service, which cleared up the errors. Opening a terminal into the Pangolin container now allows me to resolve URLs by domain name, and allows the previous
curlcommand to succeed:@kmanwar89 commented on GitHub (Nov 30, 2025):
Added the license this time, and it seems to be playing nice.
@oschwartz10612 commented on GitHub (Nov 30, 2025):
Hum strange seems like it must be a docker issue of some sort where your
containers were not getting DNS. Glad its fixed!
@kmanwar89 commented on GitHub (Nov 30, 2025):
Thanks Owen for your help. This is probably one of those "under the radar" issues that wasn't actually a problem until I needed that DNS resolution for the license check,` which wasn't the case until I applied the license. So its likely this has always been an "issue", but was never a problem until now :)