Add Tailscale integration #2679
Comments
|
@FroggyFlox this is very interesting! Thanks for the tons of exploration you've already done. My 2 cents:
I am very interested in how this will turn out, but it looks like you have already isolated the key components that will be required to integrate it into Rockstor's workflows ... |
|
@FroggyFlox Thanks for this excellent synopsis. It would be fantastic to have Tailscale integrated as a 'native' service.
Yes, this does seem like a good place to start - and would likely continue to serve us well given their mild progression on enhancing the Web-UI's capabilities. I'm a little reluctant to rely only on that however: but it may serve well just for the initial registration element: removing possibilities for us to be a 'weak-link' in this rather sensitive process.
Nice.
Agreed. Little steps as we find what folks want first/most.
Can this not be handled via the systemd service they setup?
Here I'm thinking we add it to our installers and expect it to be in-play from say our next stable release onwards. But check for it's existence during a visit to the service page - and indicate the commands required to add the repo, & install the package, if say the systemd service is not found. That way we account for folks putting in their own tailscale by means other than the upstream repo. I'm not keen on adding repos, other than our own, via Web-UI as it goes.
I know what you mean, however I think Tailscale would be worth the extra weight. It provides a previously rather difficult service that many folks struggle to achieve. So I think, if licensing is acceptable, we include by default in future installers: but instruct otherwise on repo+package add when systemd service not found.
If pre-included we need not. Plus that is again an overreach I think. I.e. we commit to supporting the upstream repo and our own capabilities with it.
I know what you mean: however there is a half-way-house here: disable the repository. Installer adds repo in disabled state: ergo no function. But our Web-UI simply enables it. But we then run the risk of folks enabling & running. Then disabling and no longer getting updates to that package(as repo disabled). Should be OK if service is off however. But again I think if we commit to carrying this repo we are good.
On this note: given the powerful/low-level/remove-access nature of TailScale we could have a "Remove" option. Which uninstalls and dumps the repo. Which upon re-visit would result in the my-hand re-instatement text being shown. @Hooverdan96
That is why I think we should try to manage via their systemd service predominantly, when-ever we can. As with all our other services: we enable/disable via upstream systemd, but configure by specialised means.
Agreed: I like the hand-off to their own Web-UI for this. I know it has less intergration, but in this case it seems worth it as we receive their security fixes/improvements in this area. We do have an existing parallel here with our treatment of the LUKS master password within the Web-UI. So we have an example. But Tailscale offer this facility for a reason is my thinking, plus what @FroggyFlox mentioned about the token approach causing a run-around. Part of this service is the ease of instantiation/initialisation. Key to our remit I think.
Agreed: I fully intend to add that Rock-on - just been sidetracked for now. So definitely a yes on having both - but I'm not sure I would agree that tailscale is majorly focused on companies. It can be easily used for simply: "I want my NAS available when I'm out and about" type think. Thanks to both of you for kicking this one off again. I was disheartened to not get more reception from my trivial request to their docker image start script previously: but all in this will be a more robust/flexible approach. And I definitely think we need such a system and to get behind it properly. Hence the addition of the repo hard-wired in the installer suggestion. Nothing hard-and-fast here on my side: just want to get this underway in a clean a way as possible. I.e. no upstream additions required that may end up unsupported or removed over time. |
|
Thanks @Hooverdan96 and @phillxnet for the feedback; that clarifies a lot of things! I'll try to summarize both of your inputs on the key points below but wanted to provide some quick follow-ups on a few points.
Agreed... I have dropped the ball completely on the rockon-registry for way too long; my apologies.
The systemd unit only runs the tailscale daemon, which only manages the network bits. The
Note also:
To the best of my knowledge, we thus need to do both: start the daemon, and then run SummaryRepo and package
A note on package size (on Leap 15.5): Configuration
Note The Toggling service ON/OFF
Thank you again for all your time! I'm sure there will be more adjustments to make as development on this begins... |
|
A potential interesting way to get the authentication status: Warning Note the warning about the possibility for changes between these flags. Logged outLogged inLogged in and Tailscale upThe output was truncated as it contained much more information about other nodes, etc... This seems to indicate we can use the Note that the tailscale cli seems to use |
Currently trying to figure out how to deal with that part. I actually realize now that The problem that needs to be solved here, is that if we run a |
|
After a couple more tests, I think our best bet is to actually use a combination of
I'm thus thinking we can do without a "login/authenticate" button in the Tailscale service configuration modal and instead show such a button next to the ON/OFF toggle switch IF we detect that authentication is indeed needed. |
|
Running Interestingly, I noticed a working option: using the The following process works:
This has been proven to work from Rockstor's UI as well. 😄 I am still curious about trying to see if we can run |
Look at you go. This is all very exiting. Looking forward to seeing all this in-action. |
Tailscale service configurationMost (all?) settings are defined as optional flags to the All supported optionsAll available flags are described in the corresponding reference: https://tailscale.com/kb/1241/tailscale-
Supported by Rockstor?We cannot offer all of these options and keep the configuration as user-friendly as Rockstor aims to be. We should thus strive to limit the number of explicit options to those likely to be the most useful/used. We can also add a custom configuration box (as for the Samba service, for instance) that would allow further customization for those interested. Below can constitute a list of most likely candidates for explicit display:
Some of the above could also be "hidden" behind an "Advanced" or "Expand" button. |
|
I now have a first attempt at the Tailscale service configuration modal, complete with validation for most fields and filtering of resulting data sent to the backend: Still needs to add some tooltips and a bit of cosmetic finishing, but that's progress. |
|
@phillxnet, @Hooverdan96: Docs: Should we?
Thanks for letting me know you preferences/ideas. |
|
@FroggyFlox Given, as you intimate, this is a major network change, I vote for:
Mouse overs of any sort are easily missed and better for help prompts: but for significant information we should really expose in some highlighted way within the form itself as per your suggestion in 3. We have such requirements elsewhere also so this can serve as our new way of hiding less in mouse overs. It could also have some kind of warning nature, just to highlight the broad nature (to the entire network) that this type of configuration represents. If I'm reading this correctly that is. All very exiting this. And the forum looks to be quite comprehensive already. You look to be dropping us into quite the Tailscale support out-of-the-gate which I'm certain will be well received. We have long needed such a feature so it's fun to see this taking shape. |
|
I would agree with the third option as well ... |
|
Thanks a lot to both of you for the prompt and helpful feedback. I will thus follow option 3.
Yeah... Adding all these options does add a little bit of complexity (enabling ip forwarding, for instance), but I know that not doing so now would probably mean it would be quite some time until these other options get implemented... I figured I might as well do it in a manner that would be fitting to what users would want to use it from the beginning. I'm still leaving the Taildrop feature our for now, though, as they do list it as an alpha feature for now (https://tailscale.com/kb/1106/taildrop/). It would make a lot of sense for a NAS, though, so I hope to add it soon. It should still be possible for users to enable it though the custom config box anyway. |
|
yes. the But some creative users also seemed to have found a workaround before this option was added: tailscale/tailscale#2312 (comment) Well, this comment is just for history keeping purposes and only pertains to one aspect of all the stuff you've already uncovered/solved for on Rockstor!!! |
|
Great finds, @Hooverdan96 , that is very helpful, especially given I'm not familiar with how Taildrop works yet so these two links are very informative to me. A loop checking for files every 5 seconds is interesting... I wonder what cost in resources that takes. Also curious about setting the destination folder... We'll have to see if there's flexibility in that. |
|
With regards to enabling IP forwarding required by some options: Tailscale documentationRecommends: openSUSE docsI did find some instructions on how to enable IP forwarding in the section related to configuring as a basic router:
It thus seems that using a dedicated |
|
In Leap 15.5, by default, IP forwarding is turned off: Create the conf files: Verify: Apply using: Verify: Reboot, and check again: To revert these changes, we can delete the conf file: As expected, this does not change the settings: Try reloading all system files: Unfortunately, no default config for IP forwarding seems to be listed in one of these files, so the settings remain: An option would thus be to manually disable IP forwarding: After a reboot, this persists (IP forwarding is still set to |
|
I now have a working (:crossed_fingers:) branch for all this so I'm currently looking into refining/expanding our current unit test coverage for |
Add support for Tailscale as a Service that can configured from
Rockstor's webUI. This commit assumes that the tailscale package is
already installed on the system.
- add "Tailscale: tailscaled" as a new service in the `prep_db.py`
script with no default configuration (null).
- add new urls endpoints with the same commands as other services:
config, start, stop.
- unlike other services, add 2 new endpoints ("children" of "config")
for the login/logout actions.
- add a new TailscaledServiceView to handle these endpoints.
- add logic to support services needing login/authentication.
- add tailscale utils functions to interface with the tailscale cli
binary.
- add flag to `system.osi.run_command()` to return raw output. This
commit does NOT change the default. Add relevant unit testing.
- increase default number of services shown in the table to 30.
- change services table column width and center buttons.
- ignore only the static/ folder located in root dir
- add unit testing to `system.services`: only partial coverage, though.
|
Closing as fixed by #2712. |
@phillxnet, @Hooverdan96, this is a proposal transfer from our previous discussion at rockstor/rockon-registry#338.
From that previous conversation, it seems the agreement was to integrate Tailscale into Rockstor at the "system" level. I'm thus opening this issue accordingly to discuss how best to do that.
Requirements
Going with this route, we would need to install the
tailscalepackage, which provides a (single?) binarytailscalethat represents the interface to manage everything. This, in turn, creates a systemd service (tailscaled).To install this package, we have a few options, but it seems the choice will be very limited. See the official instructions for install on Linux at https://tailscale.com/kb/1031/install-linux/.
They have a curl-piped-to-bash option, but that essentially does the "manual" option below.
The manual option is thus to:
tailscalepackagetailscaledsystemd servicetailscale up)The important point here is the repositories. We can go with:
https://pkgs.tailscale.com/stable/opensuse/), available for Leap 15.{1,2,3,4,5} and TW.The official repos always have the latest release available.
The OBS repo unfortunately is a bit out-of-date (a couple minor releases behind) and fails to build for Leap and TW at the moment (issue with GO build dependency).
Given we need add a repository either way, it seems using the official repos is the best choice.
Results
File system level
Using the official install instructions lead to the following new repository...
... defined with:
Note the
$basearchbit above... whether an aarch64 package exist remains to be verified!The RPM installs the following files:
The resulting systemd unit is as follows:
Activating Tailscale
Starting the systemd service leads to the following status:
We thus need to login.
Login/authentication
I see 3 main options here:
CLI
Manually run
tailscale upprints a URL to visit and authenticate the device to the user. Simple and robust, but not very practical from Rockstor's perpsective.Web portal
The
tailscalecommand has awebsubcommand that creates a simple web page to login, made for solutions like Rockstor actually. It was recently made more flexible (tailscale/tailscale@9a3bc90) but that last addition has not made it to the RPM release yet, it seems. Note it also remains to be verified whether Rockstor actually needs that last addition.This could be done as follows:
Visiting
http://buildvm155:8088brings the following:After clicking on that "Login" button, the machine is added to the user's tailnet and we can see that the activation is complete:
Note that this
tailscale webprocess is still live! We probably would need to find a way to kill it once we no longer need it.Authkey
Documentation: https://tailscale.com/kb/1085/auth-keys/
This would require us to ask the user for that key. It would be best not to store this in the database so useful only if we can pass it directly from the UI... I'm unsure whether this would be less secure, though. It also require another configuration step by the user (from Tailscale's website) so it's probably not the best option. It could be worth implementing for users who want that option, however... maybe in a later stage?
State persistence
What happens after that initial activation?
Reboot
Given the
tailscaledservice is enabled by the install instructions, it is back up and running after a reboot, and the machine is joined to the tailnet:To turn it OFF, we can run
tailscale down:Notably, this is disconnected from the
tailscaledservice as if we reboot then, thetailscaled.serviceis back active (as it was enabled), but tailscale is still down:Tailscaled and network connections
The
tailscaledservice actually "manages" the underlying connection.Indeed, when turning it ON, we now see a new connection:
Stopping the
tailscaledservice and it is now gone:Overall implementation
My first thought would be to add Tailscale as one of our supported services and would thus be listed as its own on the "System" > "Services" page. We still need to decide what happens when we configure that service, and when we toggle it ON/OFF.
Its configuration window could (at first) simply include a "login" button that would simply run the
tailscale web ...command and open a new browser page at the URL that was created by that command. Here, note that if thetailscale web ...command is run again on a machine already joined to the user's tailnet, it doesn't hurt and simply shows a "confirmation" window:We can thus keep showing that "login" button unconditionally (whether the machine is joined or not).
Later, we can think of adding configuration to other Tailscale features such as Taildrop or Tailscale SSH.
Toggling the service ON/OFF could simply run
tailscale up/tailscale down.Note that by default, each machine "expires" on a user's tailnet, which means that each user will need to re-authenticate after some time: https://tailscale.com/kb/1028/key-expiry/. All of this is configurable on Tailscale's website, but this means that we would need to catch this "expired" state to show a nice info windows prompting the user to press again the "Login" button in the Service's configuration window.
What about the tailscale package?
We also need to figure out how/when to add the tailscale RPM repo and install the package.
Should we check for this need and do that when the user clicks on the "login" button in the Service's "configuration " window? I'm still a bit unsure about that. It does seem like adding the repo and the package in the kiwi recipe would be a bit much, however, so we may just do this repo + package install "post Rockstor installation", no?
Also, should we undo this when the user turns the service OFF? This would also require to do the repo and package install when the user turns it back ON, though. It would be nice to offer a way for the user to avoid carrying an extra repository and package if they either don't use the Tailscale service, or no-longer use it.
Hope this helps begin the planning phase for this... I'm personally eager to see that implemented once we figure out how.
The text was updated successfully, but these errors were encountered: