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] confusing error message referencing "v2.Asterix" #1048

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

Originally created by @noseshimself on GitHub (Jun 21, 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

Obviously policy files had another round of breaking changes lately. There needs to be some document eplaining error messages.

I'm getting something like creating new headscale: loading ACL policy: creating policy manager: parsing policy: parsing policy from bytes: type v2.Asterix not supported and wondering if I should light a candle for Albert Uderzo.

The default installation should provide two policy files for demonstration purposes: A "permit all from any to any" and a "block all from any to any" for users as a starting point and some documentation of error messages if necessary.

Expected Behavior

Something telling me exactly what is wrong and where in which configuration file, e.g.

"policy.json: You were too stupid to add a comma on line 24, column 27"

Steps To Reproduce

  1. Launch 0.26.x with a policy.json that worked before upgrading.
  2. There is no step 2.

Environment

- Headscale version: headscale/headscale:latest

Runtime environment

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

Debug information

policy.json:

{
  "acls": [
    {
      "action": "accept",
      "src": [
        "*"
      ],
      "dst": [
        "*:*"
      ],
      "proto": [
        "*:*"
      ]
    }
  ],
  "ssh": [
    {
      "action": "accept",
      "src": [
        "*"
      ],
      "dst": [
        "*"
      ],
      "proto": [
        "*:*"
      ]
    }
  ]
}
Originally created by @noseshimself on GitHub (Jun 21, 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 Obviously policy files had another round of breaking changes lately. There needs to be some document eplaining error messages. I'm getting something like `creating new headscale: loading ACL policy: creating policy manager: parsing policy: parsing policy from bytes: type v2.Asterix not supported` and wondering if I should light a candle for Albert Uderzo. The default installation should provide two policy files for demonstration purposes: A "permit all from any to any" and a "block all from any to any" for users as a starting point and some documentation of error messages if necessary. ### Expected Behavior Something telling me exactly what is wrong and where in which configuration file, e.g. "policy.json: You were too stupid to add a comma on line 24, column 27" ### Steps To Reproduce 1. Launch 0.26.x with a policy.json that worked before upgrading. 2. There is no step 2. ### Environment ```markdown - Headscale version: headscale/headscale:latest ``` ### Runtime environment - [x] Headscale is behind a (reverse) proxy - [x] Headscale runs in a container ### Debug information policy.json: ``` { "acls": [ { "action": "accept", "src": [ "*" ], "dst": [ "*:*" ], "proto": [ "*:*" ] } ], "ssh": [ { "action": "accept", "src": [ "*" ], "dst": [ "*" ], "proto": [ "*:*" ] } ] } ```
adam added the bugpolicy 📝 labels 2025-12-29 02:27:57 +01:00
adam closed this issue 2025-12-29 02:27:57 +01:00
adam commented 2025-12-29 02:27:57 +01:00
Author
Owner
Copy Link

@nblock commented on GitHub (Jul 20, 2025):

I'm getting something like creating new headscale: loading ACL policy: creating policy manager: parsing policy: parsing policy from bytes: type v2.Asterix not supported

Yes, error messages and ACL documentation could be better. Headscale aims to implement Tailscale's ACL and their
documentation on ACL syntax has many examples that can be used as base.

The default installation should provide two policy files for demonstration purposes: A "permit all from any to any" and a "block all from any to any" for users as a starting point and some documentation of error messages if necessary.

The first case: permit all from any to any is the default behaviour, when no policy is specified and the second case
is not useful.

Here is a modified policy that loads with Headscale 0.26.1 - although your goal is not clear.

{
  "acls": [
    {
      "action": "accept",
      "src": [
        "*"
      ],
      "dst": [
        "*:*"
      ],
      "proto": "icmp"
    }
  ],
  "ssh": [
    {
      "action": "accept",
      "src": [
        "user@"
      ],
      "dst": [
        "*"
      ],
      "users": [
        "root"
      ]
    }
  ]
}

Changes include:

@nblock commented on GitHub (Jul 20, 2025): > I'm getting something like `creating new headscale: loading ACL policy: creating policy manager: parsing policy: parsing policy from bytes: type v2.Asterix not supported` Yes, error messages and ACL documentation could be better. Headscale aims to implement Tailscale's ACL and their documentation on ACL syntax has many examples that can be used as base. > The default installation should provide two policy files for demonstration purposes: A "permit all from any to any" and a "block all from any to any" for users as a starting point and some documentation of error messages if necessary. The first case: `permit all from any to any` is the default behaviour, when no policy is specified and the second case is not useful. Here is a modified policy that loads with Headscale 0.26.1 - although your goal is not clear. ```json { "acls": [ { "action": "accept", "src": [ "*" ], "dst": [ "*:*" ], "proto": "icmp" } ], "ssh": [ { "action": "accept", "src": [ "user@" ], "dst": [ "*" ], "users": [ "root" ] } ] } ``` Changes include: * The `proto` key in the `acls` section requires a protocol: `icmp`, `udp`, `tcp`, … * [The `src` key in the `ssh` section does not allow a wildcard](https://tailscale.com/kb/1193/tailscale-ssh#src) * There is no `proto` key in the `ssh` section. * Add the `users` key to the `ssh` section: allow to login as `root` using tailscale ssh
adam commented 2025-12-29 02:27:57 +01:00
Author
Owner
Copy Link

@noseshimself commented on GitHub (Jul 30, 2025):

I'm currently getting

2025-07-29T22:55:45Z ERR user msg: node not found code=404

every few seconds -- at least consider adding which node was being looked up and maybe by whom and how. Right this it is not helping in any way.

@noseshimself commented on GitHub (Jul 30, 2025): I'm currently getting ``` 2025-07-29T22:55:45Z ERR user msg: node not found code=404 ``` every few seconds -- at least consider adding *which* node was being looked up and maybe by whom and how. Right this it is not helping in any way.
adam commented 2025-12-29 02:27:57 +01:00
Author
Owner
Copy Link

@afonsofrancof commented on GitHub (Aug 22, 2025):

Now that #2734 has been merged, an empty dictionary corresponds to allow all.
And the documentation on ACLs has been changed to reflect that.
Just have to wait for the next release

@afonsofrancof commented on GitHub (Aug 22, 2025): Now that #2734 has been merged, an empty dictionary corresponds to `allow all`. And the documentation on ACLs has been changed to reflect that. Just have to wait for the next release
adam commented 2025-12-29 02:27:57 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Sep 9, 2025):

@afonsofrancof, I'm catching up on issues left for 0.27, does this mean that we should likely not hit this case anymore and this can be considered fixed in #2734?

@kradalby commented on GitHub (Sep 9, 2025): @afonsofrancof, I'm catching up on issues left for 0.27, does this mean that we should likely not hit this case anymore and this can be considered fixed in #2734?
adam commented 2025-12-29 02:27:57 +01:00
Author
Owner
Copy Link

@afonsofrancof commented on GitHub (Sep 9, 2025):

@afonsofrancof, I'm catching up on issues left for 0.27, does this mean that we should likely not hit this case anymore and this can be considered fixed in #2734?

There is now an easier way to allow and deny all. But idk if this bug could still show up in different scenarios other than allow all or deny all.

@afonsofrancof commented on GitHub (Sep 9, 2025): > @afonsofrancof, I'm catching up on issues left for 0.27, does this mean that we should likely not hit this case anymore and this can be considered fixed in #2734? There is now an easier way to allow and deny all. But idk if this bug could still show up in different scenarios other than allow all or deny all.
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 policy 📝
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#1048
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?