starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-11 20:00:28 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

[Bug] policy check complaining about users not being found in beta #1013

New Issue
Closed
opened 2025-12-29 02:27:31 +01:00 by adam · 3 comments
adam commented 2025-12-29 02:27:31 +01:00
Owner
Copy Link

Originally created by @ich777 on GitHub (May 9, 2025).

Is this a support request?

  • This is not a support request

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

When running headscale policy check -f /etc/headscale/acls.hujson there are many errors listed that non of the users are found:
Image

However when starting Headscale no errors are displayed and everything is working as expected, I assume the errors are displayed because Headscale has no access to the database when running it like that through docker exec (the container is running, however even when running headscale policy check -f /etc/headscale/acls.hujson -c /etc/headscale/config.yaml it's not working.

Additionally is there some documentation on Policy v2?

Expected Behavior

Show that Policy is valid since the Headscale log shows no errors.

Steps To Reproduce

  1. Update container to latest beta
  2. Make necessary changes to acls.hujson so that users contain a trailing @ (please note that I don't use email addresses on my instance)
  3. Run headscale policy check -f /etc/headscale/acls.hujson

Environment

- OS: Unraid 7.1.1-rc.1.1 (Slackware Current)
- Headscale version: 0.26.0-beta.1
- Tailscale version: 1.82.5

Runtime environment

  • Headscale is behind a (reverse) proxy
  • Headscale runs in a container

Debug information

I'll attach my acls.hujson for further troubleshooting: acls.txt

If more information are needed I'm happy to provide them

Originally created by @ich777 on GitHub (May 9, 2025). ### Is this a support request? - [x] This is not a support request ### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior When running `headscale policy check -f /etc/headscale/acls.hujson` there are many errors listed that non of the users are found: ![Image](https://github.com/user-attachments/assets/346c56b1-a2c8-4cd9-8d79-c7e1fdc4d579) However when starting Headscale no errors are displayed and everything is working as expected, I assume the errors are displayed because Headscale has no access to the database when running it like that through `docker exec` (the container is running, however even when running `headscale policy check -f /etc/headscale/acls.hujson -c /etc/headscale/config.yaml` it's not working. Additionally is there some documentation on Policy v2? ### Expected Behavior Show that Policy is valid since the Headscale log shows no errors. ### Steps To Reproduce 1. Update container to latest beta 2. Make necessary changes to `acls.hujson` so that users contain a trailing `@` (please note that I don't use email addresses on my instance) 3. Run `headscale policy check -f /etc/headscale/acls.hujson` ### Environment ```markdown - OS: Unraid 7.1.1-rc.1.1 (Slackware Current) - Headscale version: 0.26.0-beta.1 - Tailscale version: 1.82.5 ``` ### Runtime environment - [x] Headscale is behind a (reverse) proxy - [x] Headscale runs in a container ### Debug information I'll attach my `acls.hujson` for further troubleshooting: [acls.txt](https://github.com/user-attachments/files/20119644/acls.txt) If more information are needed I'm happy to provide them
adam added the bug label 2025-12-29 02:27:31 +01:00
adam closed this issue 2025-12-29 02:27:31 +01:00
adam commented 2025-12-29 02:27:32 +01:00
Author
Owner
Copy Link

@nblock commented on GitHub (May 9, 2025):

Additionally is there some documentation on Policy v2?

Not yet, I plan to rewrite the ACL docs to make it easier digestible. The relevant change is that users have to be specified as 'user@' and its generally more stricter.

@nblock commented on GitHub (May 9, 2025): > Additionally is there some documentation on Policy v2? Not yet, I plan to rewrite the ACL docs to make it easier digestible. The relevant change is that users have to be specified as 'user@' and its generally more stricter.
adam commented 2025-12-29 02:27:32 +01:00
Author
Owner
Copy Link

@nblock commented on GitHub (May 9, 2025):

Thanks for testing beta.1 and your report! Your policy is recognized as valid:

  • Last line is: "Policy is valid"
  • The exit code is 0

But still, the messages are printed with level TRC (depending on the terminal with red font color) and you have to look very to recognize that those are warnings. This should be improved, adding this to the release milestone.

@nblock commented on GitHub (May 9, 2025): Thanks for testing beta.1 and your report! Your policy is recognized as valid: - Last line is: "Policy is valid" - The exit code is 0 But still, the messages are printed with level `TRC` (depending on the terminal with red font color) and you have to look very to recognize that those are warnings. This should be improved, adding this to the release milestone.
adam commented 2025-12-29 02:27:32 +01:00
Author
Owner
Copy Link

@ich777 commented on GitHub (May 9, 2025):

Thanks for testing beta.1 and your report!

Sure thing, I just noticed that when I tested a few things and when I made the necessary changes for the Unraid Headsclae admin plugin.

Not yet, I plan to rewrite the ACL docs to make it easier digestible. The relevant change is that users have to be specified as 'user@' and its generally more stricter.

One other thing I noticed is that my exit nodes are visible to everyone now, I mean I'm not 100% certain but I think that wasn't the case in the last version.

@ich777 commented on GitHub (May 9, 2025): > Thanks for testing beta.1 and your report! Sure thing, I just noticed that when I tested a few things and when I made the necessary changes for the Unraid Headsclae admin plugin. > Not yet, I plan to rewrite the ACL docs to make it easier digestible. The relevant change is that users have to be specified as 'user@' and its generally more stricter. One other thing I noticed is that my exit nodes are visible to everyone now, I mean I'm not 100% certain but I think that wasn't the case in the last version.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#1013
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?