Closed masterwishx closed 2 weeks ago
adding text:
{
"groups": {
"group:admin": ["masterwishx"],
"group:family": ["user1", "user2", "user3"]
},
"tagOwners": {
"tag:cloud-server": ["group:admin"],
"tag:home-pc": ["group:admin", "group:family"],
"tag:home-pc-vm": ["group:admin"],
"tag:home-server": ["group:admin"],
"tag:home-server-vm": ["group:admin"],
"tag:home-mobile": ["group:admin", "group:family"],
"tag:home-mobile-vm": ["group:admin", "group:family"]
},
"acls": [
{
// admin have access to all servers
"action": "accept",
"src": ["group:admin"],
"dst": ["*:*"]
},
{
// family have access to all home pcs,Speedtest Tracker
"action": "accept",
"src": ["group:family"],
"dst": ["tag:home-pc:*", "tag:home-server:9443", "tag:home-server:8180"]
}
// We still have to allow internal users communications since nothing guarantees that each user have
// their own users.
//{ "action": "accept", "src": ["admin"], "dst": ["admin:*"] },
//{ "action": "accept", "src": ["family"], "dst": ["family:*"] }
],
"ssh": [
{
"action": "accept",
//"src": ["tag:cloud-server", "tag:home-server", "tag:home-pc"],
"src": ["group:admin"],
"dst": ["tag:cloud-server", "tag:home-server"],
"users": ["root", "ubuntu", "abc"]
}
]
}
@masterwishx could you run
tailscale debug netmap
on one of the ssh dst hosts?
@masterwishx could you run
tailscale debug netmap
on one of the ssh dst hosts?
Sure, will post here...
i think like no acl file was located when tryed beta1
When goes back to alpha12 have on same machine:
I too having issues with acl’s. In alpha12 nodes that don’t have access to other nodes, now can access other nodes in beta1, when using file mode.
Appears file mode does not work. I switched to database mode then headscale policy set -f [path to acl file]
Then headscale policy get
, and can see all acls.
Now restricted nodes based on acl can’t communicate to other nodes as configured.
@pallabpain, let me know if you could help have a look at this one, might not be related, but worth a check.
@kradalby Sure. I'll take a look at this. From what @seanob86 reported, I can probably investigate the part when ACL is loaded from a file and whether I messed it up during the re-write. 😅
I also encountered an issue after upgrading to beta1.
My config contains:
acl_policy_path: "/etc/headscale/acls.hujson"
policy:
mode: file
path: "/etc/headscale/acls.hujson"
Without acl_policy_path
, ACLs do not work at all. headscale policy get
returns no ACLs in that case.
When using the deprecated acl_policy_path
, everything works and headscale policy get
returns the ACLs accordingly.
As previously mentioned, it seems ACLs are not loaded correctly when using the new file mode.
I also encountered an issue after upgrading to beta1.
My config contains:
acl_policy_path: "/etc/headscale/acls.hujson" policy: mode: file path: "/etc/headscale/acls.hujson"
Without
acl_policy_path
, ACLs do not work at all.headscale policy get
returns no ACLs in that case. When using the deprecatedacl_policy_path
, everything works andheadscale policy get
returns the ACLs accordingly. As previously mentioned, it seems ACLs are not loaded correctly when using the new file mode.
That's what I wrote in discord
@kradalby @pallabpain
can confirm after added : acl_policy_path: "/etc/headscale/acls.json"
all working fine
I confirm having this bug too. I suggest removing the "for SSH" part in the title as the issue affects all ACLs.
I know this is 99% certain that it is related to the ACL changes, but could you help test if the DNS breakage had an impact?
I think #2034 addresses DNS issues, would it be possible for you to help me test it? would be great to avoid another bad release like beta1.
Binary is available here: https://github.com/juanfont/headscale/actions/runs/10195837541?pr=2034
I know this is 99% certain that it is related to the ACL changes, but could you help test if the DNS breakage had an impact?
I think #2034 addresses DNS issues, would it be possible for you to help me test it? would be great to avoid another bad release like beta1.
Binary is available here: https://github.com/juanfont/headscale/actions/runs/10195837541?pr=2034
Sure I can check it tomorrow, what is link for docker? :pr2034
Also I don't have any dns issues for now with beta1, but also installed and using Adguard home as container in host network and using it in config as dns, enabled also tailscale dns on same host becose otherwise magic DNS not working in this machine
Sure I can check it tomorrow, what is link for docker? :pr2034
We do not build docker containers for prs/branches sadly, so you will have to build it.
Sure I can check it tomorrow, what is link for docker? :pr2034
We do not build docker containers for prs/branches sadly, so you will have to build it.
OK, got it. Did you asked from me to check?
Sure I can check it tomorrow, what is link for docker? :pr2034
We do not build docker containers for prs/branches sadly, so you will have to build it.
Can you give a hint how to build docker for this pr, I'm not sure
can confirm after added : acl_policy_path: "/etc/headscale/acls.json" all working fine
I think I've found the error, Cobra, the framework we use for reading the config file has a lot of sharp edges for aliases from old to new configs, so I will make the acl_policy_path
a hard error and only read the new one.
Sorry for the inconvenience!
can confirm after added : acl_policy_path: "/etc/headscale/acls.json" all working fine
I think I've found the error, Cobra, the framework we use for reading the config file has a lot of sharp edges for aliases from old to new configs, so I will make the
acl_policy_path
a hard error and only read the new one.Sorry for the inconvenience!
It's OK, I'm really sorry for was unable to help becose of docker build...
can confirm after added : acl_policy_path: "/etc/headscale/acls.json" all working fine
I think I've found the error, Cobra, the framework we use for reading the config file has a lot of sharp edges for aliases from old to new configs, so I will make the
acl_policy_path
a hard error and only read the new one.Sorry for the inconvenience!
@kradalby Yes, that was my hunch as well. Apologies for not being able to take a look at the issue.
Per this comment, the db
mode works fine and only file mode was unable to get the file path.
Thanks for addressing the issue. :)
also had this issue, why is YAML no longer supported for ACLs? it's so much easier to edit in something like nano/vim
also had this issue, why is YAML no longer supported for ACLs? it's so much easier to edit in something like nano/vim
We are reducing the maintenance cost for developers, sorry for the inconvenience, but we will only support one format (hujson) forward.
also had this issue, why is YAML no longer supported for ACLs? it's so much easier to edit in something like nano/vim
We are reducing the maintenance cost for developers, sorry for the inconvenience, but we will only support one format (hujson) forward.
Can't you just add like 2-3 lines of code, if the files ends with .yaml
then convert it over to JSON first? I'm down to submit a patch because yaml genuinely makes this so much easier to manage on a server over SSH, editing JSON over SSH is just painful.
Is this a support request?
Is there an existing issue for this?
Current Behavior
SSH not working after updated to beta1 and changed config for it:
Expected Behavior
wokring in versions befor
Steps To Reproduce
...
Environment
Runtime environment
Anything else?
No response