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 license key 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
OS Type & Version: (e.g., Ubuntu 22.04): Ubuntu Server 24.04 LTS
Pangolin Version: Enterprise v1.12.2
Gerbil Version: N/A
Traefik Version:
Newt Version:
Olm Version: (if applicable)
(I'm not certain how to retrieve the above versions)
To Reproduce
Request a license key
Apply it to self hosted instance
Observe screenshotted error message
(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.
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:
<img width="751" height="90" alt="Image" src="https://github.com/user-attachments/assets/a57f9f35-4aba-49f4-aad9-429d0a6edda1" />
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?
<img width="1585" height="809" alt="Image" src="https://github.com/user-attachments/assets/57d3be34-cbfa-4517-8b18-e1bb852613e0" />
If I check the `license` key 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.
<img width="1592" height="297" alt="Image" src="https://github.com/user-attachments/assets/d5a57d51-43b4-4a0b-bf91-5c1ab988357d" />
Deleting, and re-adding, the license key yields a "failed to fetch" error:
<img width="527" height="158" alt="Image" src="https://github.com/user-attachments/assets/606182ae-4f91-4b00-a0a2-2083d0e67017" />
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
- OS Type & Version: (e.g., Ubuntu 22.04): Ubuntu Server 24.04 LTS
- Pangolin Version: Enterprise v1.12.2
- Gerbil Version: N/A
- Traefik Version:
- Newt Version:
- Olm Version: (if applicable)
(I'm not certain how to retrieve the above versions)
### To Reproduce
1. Request a license key
2. Apply it to self hosted instance
3. Observe screenshotted error message
(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?
<!-- gh-comment-id:3591759074 -->
@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`?
Nice to hear from you Owen - I'm certain I keep you guys busy ;)
Looks like I cannot curl it from within the container:
❯ docker exec -it pangolin curl https://api.fossorial.io/api/healthcheck
curl: (6) Could not resolve host: api.fossorial.io
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.
/app # date
Sat Nov 29 17:09:11 UTC 2025
/app # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=112 time=13.942 ms
64 bytes from 8.8.8.8: seq=1 ttl=112 time=13.670 ms
64 bytes from 8.8.8.8: seq=2 ttl=112 time=13.615 ms
64 bytes from 8.8.8.8: seq=3 ttl=112 time=13.597 ms
64 bytes from 8.8.8.8: seq=4 ttl=112 time=13.623 ms
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 13.597/13.689/13.942 ms
/app # date
Sat Nov 29 17:09:18 UTC 2025
<!-- gh-comment-id:3591810555 -->
@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:
```
❯ docker exec -it pangolin curl https://api.fossorial.io/api/healthcheck
curl: (6) Could not resolve host: api.fossorial.io
```
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.
```
/app # date
Sat Nov 29 17:09:11 UTC 2025
/app # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=112 time=13.942 ms
64 bytes from 8.8.8.8: seq=1 ttl=112 time=13.670 ms
64 bytes from 8.8.8.8: seq=2 ttl=112 time=13.615 ms
64 bytes from 8.8.8.8: seq=3 ttl=112 time=13.597 ms
64 bytes from 8.8.8.8: seq=4 ttl=112 time=13.623 ms
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 13.597/13.689/13.942 ms
/app # date
Sat Nov 29 17:09:18 UTC 2025
```
@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
<!-- gh-comment-id:3591948553 -->
@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
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 curl command to succeed:
<!-- gh-comment-id:3592071939 -->
@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 `curl` command to succeed:
```
❯ docker exec -it pangolin curl https://api.fossorial.io/api/healthcheck
{"data":null,"success":true,"error":false,"message":"Hello world!","status":200}%
```
Added the license this time, and it seems to be playing nice.
<!-- gh-comment-id:3592072462 -->
@kmanwar89 commented on GitHub (Nov 30, 2025):
<img width="1626" height="863" alt="Image" src="https://github.com/user-attachments/assets/30a7fa76-a1ea-44d0-a3ca-997e3e564f7a" />
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!
<!-- gh-comment-id:3592172768 -->
@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!
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 :)
<!-- gh-comment-id:3592574949 -->
@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 :)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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 :)