Years ago I had the fun of hunting down a bug at 3am before a game launch. Randomly, we’d save the game and instead get an empty file. This is pretty much the worst thing a game can do (excepting wiping your hard drive, hello Bungie). Turned out some analytics framework was leaking network connections and thus stealing all our file handles. :(
Vaguely related - there’s still no easy way to get at the email/user name of a user using tailscale ssh right? This is one of the things I really liked about teleport, you could use it to properly attribute git commits on shared machines, without any special setup on the user side.
No, for disambiguating between multiple users logging into one shared account. Basically, I'd need for tailscale to inject an env variable into the session. Teleport does this with something like SSH_TELEPORT_USER (I don't have access to a teleport instance right now to check the exact name, sorry). It's not really for security purposes (anyone can spoof any env variable they like, anyhow), just for convenience for helper scripts. In robotics it's super common to have just one or two users per machine, and give shared logins to those machines.
While I have you here, it would also be neat if there were a way to supplement regular SSH's auth with tailscale SSH's keys. Specifically for situations where the target machine has lost internet connectivity but you can still get onto the same network as it. More robotics problems. :) Can understand if this would never "work" for tailscale's auth model.
Yeah this is all great feedback, thanks. Makes sense about the env var!
On the second item- this is interesting. I definitely see the reason for asking :) We actually don’t use SSH keys for Tailscale SSH, since the auth is handled within Tailscale (more info at https://tailscale.com/kb/1193/tailscale-ssh#authentication-a...). I’ll think more about this. Do you have a break-glass setup with a normal SSH key for this today?
For Ubuntu it’s possible to use debootstrap to install to an external drive directly. Once you’ve done that, you can chroot into the new drive, fix up a few things that aren’t handled (mounts, locale), then install any software you want on top. Even stuff like installing new kernel/drivers works. Running docker in the chroot also works, if you copy the setup used in docker-in-docker. I wonder if a similar setup is usable here.
Side note wrt tailscale - you should be able to auth without manual registration. Two choices:
1. Make a reusable key that grants the ACL you want to give, store it somewhere secure on your provisioner, then “ssh user@tag sudo tailscale up —-auth-key=$key” to deploy.
2. Make a new tag for “disabled-machine” or similar, locked down with no access. Embed that key in your ISO and use whatever mechanism you have to start it up on boot.
Either way you no longer have to copy paste the setup link to your browser, and the machine always starts off with the ACL tags you want (setting an ACL tag automatically disables expiration btw - no need to do both).
2 is likely tricky to do securely, so take care. :)
Spent way too much time working on getting this working over the past week, hopefully someone other than me learns something from it. As far as I know I’m the first to actually document it, if not the first to get an environment that works with threading.
My issue with it is how easy it is to allocate all over the place if you forget to use inplace operations. It's even worse with cupy - rather than applying a series of operations to some data to produce some other data, you end up producing a set of data for each operation. Yes, there are workarounds, but they aren't as ergonomic (cupy.fuse() almost does the right thing, cleanly, but is a step you have to remember to use, and doesn't really work for anything that requires multiple shapes of array).
reply