Hello @m1guelpf , thank you for doing this!

For now, we don't build all of our binaries on demand; but id love to see this added! If you don't mind, can you reformat this PR to follow our current method?

Specifically:

• Build a binary, and place it in ./prebuilt
• Update ./prebuilt/COMPILE.md with build instructions using our existing docker image. This is so later when we get to full-build automation, the build steps are documented. :)
• symlink the binary to where you want it in the image, I assume /usr/bin, so use images/cfw/usr/bin
• update the cfw.pack file with the binary example: file /usr/bin/tailscale 755 0 0. File in question is https://github.com/X1Plus/X1Plus/blob/main/images/cfw.pack

Discord discussion starts at https://discord.com/channels/1041781310299062282/1184978673313534072/1233161269297807390

LGTM, would like a review from @jwise before merging.

Hmmm I'm sort of of two minds here.

On the one hand, it is nice to have a compiled Tailscale binary for our platform.

On the other hand, we do not have UI to use it yet, and until it gets more use, it means we are forever lugging around yet another 5MB binary in our .git that is not plugged into the build anywhere :-)

I wonder if this should go in, like, an x1plus-contrib repository or something?

Hmmm I'm sort of of two minds here.

On the one hand, it is nice to have a compiled Tailscale binary for our platform.

On the other hand, we do not have UI to use it yet, and until it gets more use, it means we are forever lugging around yet another 5MB binary in our .git that is not plugged into the build anywhere :-)

I wonder if this should go in, like, an x1plus-contrib repository or something?

my 2c, for now we merge this because sitting in git is no big deal, 5M is nothing considering it won't go in the final disk image. I just don't like a useful contribution sitting around due to our indecision; id rather we refactor this out later once we have an idea how "contrib" tools/binaries will get packaged for x1plus.

So I am ok with leaving this open, and I do not think I call it indecision :)

I don’t really want to haul another 5MB around in an already kind of big .git directory, and in general, I tend to believe that code / a resource that lives in a repository but is not regularly tested — let alone something that is not ever compiled in! — is sort of a liability. (Not that I think that this is the case for Miguel, but it is still fresh on my mind the recent case of the liblzma thing, which was exactly because they were hauling around a large opaque blob that was tested!)

So I am happy to leave this open, especially as a resource pointer to anyone who might want to do this on their own printer and wished they had a precompiled image. I don’t see how to merge it yet, but that’s not to say that I don’t think it will ever be merged (or used in some capacity), and it is real useful valuable work that I don’t think we should just close. After all, we have lots of issues that are open long term — I don’t see a reason why that shouldn’t be the case for a PR also?

@m1guelpf I was looking into Tailscale build flags that might reduce the size of the binary and found this -
https://tailscale.com/kb/1207/small-tailscale

Not only is there a special flag for this but there are also options to omit other things that carry a lot of dependencies:
build_dist.sh --extra-small
tailscale/tailscale#5198

If that knocks the file size down to 2-3 mb, it would be a lot more manageable. Not a requirement by any means, but I thought you might be interested.

@jphannifan this PR already includes all the strategies suggested by that page 😁

@jphannifan this PR already includes all the strategies suggested by that page 😁

ah I didn't see your build script the first time around. I'm surprised it's still at 5 mb then.

What if instead of packing the binary into an x1p file, you included a shell script in /usr/bin/ that runs wget to download this binary from Github? Anyone who wants to install it can at any time by running the script. The binary would be on Github still, but it wouldn't be bundled with the installer archive

@jphannifan I believe suggested this on Discord at some point, but it got lost in discussion. Here's what I'm thinking would work best:

• Symlink /var/lib/tailscale/tailscaled.state to the SD card at /x1plus/printers/<serialnumber>/tailscale
• Add an init.d service that runs tailscaled if a config file is found at the above path.
• Add a tailscale bash script to the image which just replaces itself with the downloaded binary and starts the daemon.

With these changes, an user should be able to run a tailscale command (like tailscale up), get a message saying that tailscale has been installed and they should try again, then run the command again with the expected results (plus settings should persist thru updates).

@m1guelpf that sounds good to me. I would see no issues with this PR being approved and merged once this is working.

Because every X1Plus update will wipe out the init.d script, here is my suggestion:

• The bash script /x1plus/printers/<serialnumber>/tailscale first checks to see if the binary has been downloaded
• If it's not yet downloaded, it does so and stores it in /x1plus/printers/<serialnumber>/bin/
• cp the binary to /usr/bin/. Also save an init.d script to /etc/init.d/
• init.d script checks for config file before starting the daemon
  • if config file absent --> make a new config before the daemon starts

This way the file only needs to be downloaded once, and if the config file is removed or lost, the init.d script will take care of it.

Seems like this discussion died waiting for someone to approve on a check that failed. Is that accurate, or did the discord conversation supercede this? Only asking because I was poking around trying to determine how to use to docker to set up a cross-compile environment to buid tailscale, and stumbled in here. If binaries already exist, point me the way - if not, I'll keep digging. Have my printers on 2.0 release currently.