A tailscale Rock-on would be nice

[phillxnet]

There is the following official Tailscale docker image:
https://hub.docker.com/r/tailscale/tailscale

But it's not looking like we need it to currently. Just noting here in case we get any takers or the work to adapt to this rock-on within the rockstor-core takes anyone's fancy. Or if anyone can fathom a way we can get this official docker image in as-is. It could go in with command line caveats/post install setup but that's really not in the Rock-on remit really.

[phillxnet]

This issue is awaiting the final testing/review/and merge of #336 to help clear the way before adding yet more Rock-ons.

[phillxnet]

I am currently working on this issue.

[phillxnet]

Given the requirement of the official docker image of Tailscale, the hightly preferred option given the security and network concernes here, is it thought that we would need custom custom config & start options such as are employed (in config and install) for our current open-vpn and owncloud rock-ons here:

https://github.com/rockstor/rockstor-core/blob/master/src/rockstor/storageadmin/views/rockon_helpers.py

Given that such treatment would lock any Tailscale Rock-on here to only future Rockstor versions it is currently considered that the development time may well be better spent on intergrating Tailscale 'properly' as a service, which is what it runs as anyway (using a go binary). Repo addition logistic is a related concern here. Expect a newer issue in core and the likely closing of this issue if there is not further follow up for some time.

Stick point in Rock-on development was the passing of an authentication key:
From: https://hub.docker.com/r/tailscale/tailscale

We require the input of a pre-created via tailscale dash settings-key tailnet auth key and for this to be passed to the docker container via:

docker exec tailscaled tailscale up --authkey=$KEY

Hence the suggestion that our current setup could do this only via custom_config

  (optional)"custom_config": <custom configuration object that a special install handler of this Rock-on expects>

entry and dedicated rockon.name.lower()_start and/or install code adition.

Noting here just in case this is re-visited. But the current side channel consensus with admittedly only parsing consideration is that Tailscale is sufficiently inportant to adopt as a core service where we can vastly improve our intergration/compatibility in-comparison to supporting only from a Rock-on where we have already run into an implementation issue.

My apologies if I've missed an obviously implementation trick here.
I'll leave this issue open for a while to allow input on potential work-arounds. I'm really not keen on having folks drop to a terminal as such a work around. They may as well install via command line in the first place if that is the way we end up going with such things. We do have this still in some Rock-ons but they are likely to be removed or improved in time hopefully. And adding yet another cli requiring Rock-on doesn't seem like the way forward.

[phillxnet]

Closing as an attempt in the linked pr was meat with upstream resistance.