github-starred/newt
2
0
Fork 0
mirror of https://github.com/fosrl/newt.git synced 2026-03-08 23:03:03 -05:00
Code Issues 21 Packages Projects Releases 25 Wiki Activity

Docker labels breaking Pangolin if duplicate names are used #67

New Issue
Open
opened 2025-11-19 07:13:10 -06:00 by GiteaMirror · 0 comments
GiteaMirror commented 2025-11-19 07:13:10 -06:00
Owner
Copy Link

Originally created by @DennisGaida on GitHub (Oct 19, 2025).

Describe the Bug

Trying to make Pangolin be more config based, I want to leverage docker labels, just like I am able with traefik.

Unfortunately labels (blueprints) seem to be yanky currently. Having duplicate label names on different machines connected via newt completely breaks Pangolin and I have to fix stuff in the sqlite database.

Environment

  • OS Type & Version: Ubuntu & Debian
  • Pangolin Version: 1.11
  • Gerbil Version: 1.2.2
  • Traefik Version: 3.5.3
  • Newt Version: 1.5.2

To Reproduce

  1. Have RemoteMachine1 configured via labels:
  [...]
  labels:
      ## Pangolin via Newt
      pangolin.proxy-resources.syncthing.name: syncthing
      pangolin.proxy-resources.syncthing.full-domain: syncthing1.domain.example.com
      pangolin.proxy-resources.syncthing.protocol: http
      pangolin.proxy-resources.syncthing.auth.sso-enabled: "true"
      pangolin.proxy-resources.syncthing.targets[0].method: http
      pangolin.proxy-resources.syncthing.targets[0].hostname: syncthing
      pangolin.proxy-resources.syncthing.targets[0].port: 8384
  1. Observe the resource being pushed to Pangolin. Is also accessible via syncthing.domain.example.com
  2. Now configure RemoteMachine2 via labels:
  [...]
  labels:
      ## Pangolin via Newt
      pangolin.proxy-resources.syncthing.name: syncthing
      pangolin.proxy-resources.syncthing.full-domain: syncthing2.domain.example.com
      pangolin.proxy-resources.syncthing.protocol: http
      pangolin.proxy-resources.syncthing.auth.sso-enabled: "true"
      pangolin.proxy-resources.syncthing.targets[0].method: http
      pangolin.proxy-resources.syncthing.targets[0].hostname: syncthing
      pangolin.proxy-resources.syncthing.targets[0].port: 8384
  1. Observe that I only changed the full-domain.
  2. What happens now is the following:
  • Pangolin does not create the second resource, but deletes things
  • After a restart (don't remember whether it was Pangolin itself, gerbil or newt), I get infinite authentication redirects
  • These redirects cannot be fixed in Traefik and are directly related to Badger (since it's doing the redirecting)
  • Checking the database I can tell it is broken
  1. All resources that were added via any docker label from any machine are broken after adding the duplicate-name resource❗
Image

The database now contains (NULL) for all subdomain that are configured via newt agents. The fullDomain is set to the base domain (if the subdomain would have been syncthing2.domain.example.com, fullDomain now is domain.example.com). This leads to an infinite redirect since there are multiple endpoints for the base domain (the base domain is also where my Pangolin is hosted, i.e. domain.example.com is Pangolin.

The only way to fix this is to manually edit the database and specify subdomain & fullDomain for the broken entries. To fix the database I have to stop Pangolin, then start it again and also restart traefik.

After playing around with this some more, I also figured out that the label key pangolin.proxy-resources.**<name>**.name is important, next to the value of the name itself. This really isn't represented in the documentation. I guess the best practice right now is then to create the following configuration if I had two services that are essentially the same, besides the host:

host1:

  [...]
  labels:
      pangolin.proxy-resources.syncthing-host1.name: syncthing-host1
      pangolin.proxy-resources.syncthing-host1.full-domain: syncthing-host1.domain.example.com
      pangolin.proxy-resources.syncthing-host1.protocol: http
      pangolin.proxy-resources.syncthing-host1.auth.sso-enabled: "true"
      pangolin.proxy-resources.syncthing-host1.targets[0].method: http
      pangolin.proxy-resources.syncthing-host1.targets[0].hostname: syncthing
      pangolin.proxy-resources.syncthing-host1.targets[0].port: 8384

host2:

  [...]
  labels:
      pangolin.proxy-resources.syncthing-host2.name: syncthing-host2
      pangolin.proxy-resources.syncthing-host2.full-domain: syncthing-host2.domain.example.com
      pangolin.proxy-resources.syncthing-host2.protocol: http
      pangolin.proxy-resources.syncthing-host2.auth.sso-enabled: "true"
      pangolin.proxy-resources.syncthing-host2.targets[0].method: http
      pangolin.proxy-resources.syncthing-host2.targets[0].hostname: syncthing
      pangolin.proxy-resources.syncthing-host2.targets[0].port: 8384

Expected Behavior

Pangolin shouldn't break like this due to a misconfiguration of docker labels - worse yet, having to remember to not re-use an ID I already used on another host. If an ID already exists, just add a -1 or whatever as a suffix.

Originally created by @DennisGaida on GitHub (Oct 19, 2025). ### Describe the Bug Trying to make Pangolin be more config based, I want to leverage docker labels, just like I am able with traefik. Unfortunately labels (blueprints) seem to be yanky currently. Having duplicate label names on different machines connected via newt completely breaks Pangolin and I have to fix stuff in the sqlite database. ### Environment - OS Type & Version: Ubuntu & Debian - Pangolin Version: 1.11 - Gerbil Version: 1.2.2 - Traefik Version: 3.5.3 - Newt Version: 1.5.2 ### To Reproduce 1. Have RemoteMachine1 configured via labels: ``` [...] labels: ## Pangolin via Newt pangolin.proxy-resources.syncthing.name: syncthing pangolin.proxy-resources.syncthing.full-domain: syncthing1.domain.example.com pangolin.proxy-resources.syncthing.protocol: http pangolin.proxy-resources.syncthing.auth.sso-enabled: "true" pangolin.proxy-resources.syncthing.targets[0].method: http pangolin.proxy-resources.syncthing.targets[0].hostname: syncthing pangolin.proxy-resources.syncthing.targets[0].port: 8384 ``` 2. Observe the resource being pushed to Pangolin. Is also accessible via syncthing.domain.example.com 3. Now configure RemoteMachine2 via labels: ``` [...] labels: ## Pangolin via Newt pangolin.proxy-resources.syncthing.name: syncthing pangolin.proxy-resources.syncthing.full-domain: syncthing2.domain.example.com pangolin.proxy-resources.syncthing.protocol: http pangolin.proxy-resources.syncthing.auth.sso-enabled: "true" pangolin.proxy-resources.syncthing.targets[0].method: http pangolin.proxy-resources.syncthing.targets[0].hostname: syncthing pangolin.proxy-resources.syncthing.targets[0].port: 8384 ``` 4. Observe that I only changed the full-domain. 5. What happens now is the following: - Pangolin does not create the second resource, but deletes things - After a restart (don't remember whether it was Pangolin itself, gerbil or newt), I get infinite authentication redirects - These redirects cannot be fixed in Traefik and are directly related to Badger (since it's doing the redirecting) - Checking the database I can tell it is broken 6. **All** resources that were added via any docker label from any machine are broken after adding the duplicate-name resource❗ <img width="991" height="202" alt="Image" src="https://github.com/user-attachments/assets/c13f9b7f-d363-4c93-93cc-e05a5a42c513" /> The database now contains `(NULL)` for all `subdomain` that are configured via newt agents. The `fullDomain` is set to the base domain (if the subdomain would have been `syncthing2.domain.example.com`, `fullDomain` now is `domain.example.com`). This leads to an infinite redirect since there are multiple endpoints for the base domain (the base domain is also where my Pangolin is hosted, i.e. `domain.example.com` is Pangolin. The only way to fix this is to manually edit the database and specify subdomain & fullDomain for the broken entries. To fix the database I have to stop Pangolin, then start it again and also restart traefik. --- After playing around with this some more, I also figured out that the label key `pangolin.proxy-resources.**<name>**.name` is important, next to the value of the name itself. This really isn't represented in the documentation. I guess the best practice right now is then to create the following configuration if I had two services that are essentially the same, besides the host: host1: ``` [...] labels: pangolin.proxy-resources.syncthing-host1.name: syncthing-host1 pangolin.proxy-resources.syncthing-host1.full-domain: syncthing-host1.domain.example.com pangolin.proxy-resources.syncthing-host1.protocol: http pangolin.proxy-resources.syncthing-host1.auth.sso-enabled: "true" pangolin.proxy-resources.syncthing-host1.targets[0].method: http pangolin.proxy-resources.syncthing-host1.targets[0].hostname: syncthing pangolin.proxy-resources.syncthing-host1.targets[0].port: 8384 ``` host2: ``` [...] labels: pangolin.proxy-resources.syncthing-host2.name: syncthing-host2 pangolin.proxy-resources.syncthing-host2.full-domain: syncthing-host2.domain.example.com pangolin.proxy-resources.syncthing-host2.protocol: http pangolin.proxy-resources.syncthing-host2.auth.sso-enabled: "true" pangolin.proxy-resources.syncthing-host2.targets[0].method: http pangolin.proxy-resources.syncthing-host2.targets[0].hostname: syncthing pangolin.proxy-resources.syncthing-host2.targets[0].port: 8384 ``` ### Expected Behavior Pangolin shouldn't break like this due to a misconfiguration of docker labels - worse yet, having to remember to not re-use an ID I already used on another host. If an ID already exists, just add a `-1` or whatever as a suffix.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
good first issue
help wanted
Improvement
pull-request
Mirrored from GitHub Pull Request
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/newt#67
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?