Fundamentally, they are very similar, and of course some inspiration (though no code) was taken primarily from headscale-ui. Mine differs I think in a couple minor ways:
- Improved reactivity, things update quickly and feels very snappy.
- Good navigation, easily able to open user info from a node, and navigate to other nodes owned by a user, etc
- A deploy page to aid in the `tailscale up` command when provisioning new nodes.
In the near future, I would also like to have ACL support which is a different beast entirely, but was the original goal for creating my program in the first place.
Nice! Any plans for ACLs? Unfortunately my project stalled out due to other work related projects.
It is definitely in my plans. The issue is that the API doesn't expose any interaction with it, so I need to write a separate service that exposes its own API to interact with the HuJSON ACL file. It's definitely possible, and I've even thought of possibly using SSR and having headscale-admin interact with the ACL file directly, but decided against it just to keep headscale-admin fully static and portable.
This is a really well considered development, the functionality is simple and elegant. The fact it runs really smoothly and looks very pretty is a bonus!
thanks. it is great. I'm eagerly following dev-acl
Great. Headscale-webui is quite slow. I'll try yours
It’s still early in the development stages, so any improvement ideas or bugs are more than welcome!
u/GoodiesHQ This is definitely an awesome admin console. I think I will stick with this one over the headscale-ui.
Feature Request:
Local storage path for custom .css files that the container looks for upon loading. That way it gives the end user the ability to create themes of their own and apply them without affecting the themes already created.
This would give the end user the ability to add company or personal logo, change placements of things, create smaller footprint and hide elements they dont wish to see.
This also ensures that if the ui changes in any way, only the custom css file is broken and to alleviate the problem, the user can just rename or remove the css file temporarily and restart the container and all is back to being fixed until the end user fixes their .css file.
Fundamentally, they are very similar, and of course some inspiration (though no code) was taken primarily from headscale-ui. Mine differs I think in a couple minor ways:
- Improved reactivity, things update quickly and feels very snappy.
- Good navigation, easily able to open user info from a node, and navigate to other nodes owned by a user, etc
- A deploy page to aid in the `tailscale up` command when provisioning new nodes.
In the near future, I would also like to have ACL support which is a different beast entirely, but was the original goal for creating my program in the first place.
More replies
Nice! Any plans for ACLs? Unfortunately my project stalled out due to other work related projects.
It is definitely in my plans. The issue is that the API doesn't expose any interaction with it, so I need to write a separate service that exposes its own API to interact with the HuJSON ACL file. It's definitely possible, and I've even thought of possibly using SSR and having headscale-admin interact with the ACL file directly, but decided against it just to keep headscale-admin fully static and portable.
More replies
This is a really well considered development, the functionality is simple and elegant. The fact it runs really smoothly and looks very pretty is a bonus!
thanks. it is great. I'm eagerly following dev-acl
Great. Headscale-webui is quite slow. I'll try yours
It’s still early in the development stages, so any improvement ideas or bugs are more than welcome!
More replies
I have this issue where when i deploy the docker, it seems like nothing works. Does not take api or url. and /web is inaccessable.
a more in depth install or wiki might help
More replies
u/GoodiesHQ This is definitely an awesome admin console. I think I will stick with this one over the headscale-ui.
Feature Request:
Local storage path for custom .css files that the container looks for upon loading. That way it gives the end user the ability to create themes of their own and apply them without affecting the themes already created.
This would give the end user the ability to add company or personal logo, change placements of things, create smaller footprint and hide elements they dont wish to see.
This also ensures that if the ui changes in any way, only the custom css file is broken and to alleviate the problem, the user can just rename or remove the css file temporarily and restart the container and all is back to being fixed until the end user fixes their .css file.