Any guidance on how to get Tailscale up and running on the Steam Deck? I haven’t dug deep yet.
If you haven’t seen it yet, there’s a tutorial on the blog. It leaves a little to be desired, I think - the Tailscale service doesn’t start up automatically on boot, even when you enable it and the systemd-sysext service that should support the recommended system extension-based method.
Tomorrow I’m going to try to make it a portable service running in trusted mode and see if that lets it start up on system boot with the right networking permissions. I don’t know if that’ll let me bundle the tailscale CLI, though. I might need to use a system extension for the CLI and a portable service for the daemon.
I think I messed up some of the links. Here’s more info about portable services and portablectl.
I also got dragged out of the house yesterday, so I couldn’t get much work done.
Alright, here’s what I’ve got so far. It seems to be able to start the daemon, but then the daemon can’t find the iptables executable.
#!/usr/bin/env bash
set -eu -o pipefail
# temporary directory stuff
# dir="$(mktemp -d)"
# cd "${dir}"
# download and extract Tailscale
tarball="$(curl -s 'https://pkgs.tailscale.com/stable/?mode=json' | jq -r .Tarballs.amd64)"
version="$(echo ${tarball} | cut -d_ -f2)"
tar_dir="$(echo ${tarball} | cut -d. -f1-3)"
curl -s "https://pkgs.tailscale.com/stable/${tarball}" -o tailscale.tgz
tar xzf tailscale.tgz
test -d $tar_dir
# Set up our target directory structure
mkdir -p tailscaled/{usr/{bin,sbin,lib/systemd/system},etc,proc,sys,dev,run,/var/tmp}
# Copy tailscale-distributed files to the right place
# cp -rf $tar_dir/tailscale tailscale/usr/bin/tailscale
cp -rf $tar_dir/tailscaled tailscaled/usr/sbin/tailscaled
cp -rf $tar_dir/systemd/tailscaled.service tailscaled/usr/lib/systemd/system/tailscaled.service
# Write service os-release file
source /etc/os-release
cp -rf /etc/os-release tailscaled/etc/os-release
# temporary directory stuff
# popd
# rm -rf "${dir}"
Once you run this, you’ll have a tailscaled directory under your current working directory.
Edit the system definition file to remove the EnvironmentFile line and the --port $PORT $FLAGS options.
Run sudo portablectl attach ./tailscaled --profile=trusted to attach it, then you can use the normal systemctl commands to start/enable it.
When that fails to start, I get this in my logs:
Program starting: v1.30.0-t7fd4d617a-g7395c0dee, Go 1.19-ts6dca83b256: []string{"/usr/sbin/tailscaled", "--state=/var/lib/tailscale/tailscaled.>
LogID: 0f59ed267a2b19cc28aac9ee7119914000ca478234af8d56893a025ae72cc647
logpolicy: using $STATE_DIRECTORY, "/var/lib/tailscale"
wgengine.NewUserspaceEngine(tun "tailscale0") ...
wgengine.NewUserspaceEngine(tun "tailscale0") error: creating router: exec: "iptables": executable file not found in $PATH
flushing log.
logger closing down
createEngine: creating router: exec: "iptables": executable file not found in $PATH
I forgot about this for awhile, but it’s bugging me again. If I add
[Exec]
Environment="PATH=/usr/bin"
to the service definition, I can get this to come out in the logs:
logtail started
Program starting: v1.30.2-t24c524c78-gc399ae6fa, Go 1.19.1-tsb13188dd36: []string{"/usr/sbin/tailscaled", "--state=/var/lib>
LogID: 0f59ed267a2b19cc28aac9ee7119914000ca478234af8d56893a025ae72cc647
logpolicy: using $STATE_DIRECTORY, "/var/lib/tailscale"
wgengine.NewUserspaceEngine(tun "tailscale0") ...
wgengine.NewUserspaceEngine(tun "tailscale0") error: creating router: could not get iptables version: fork/exec /usr/bin/iptables: no such file or directory
flushing log.
logger closing down
createEngine: creating router: could not get iptables version: fork/exec /usr/bin/iptables: no such file or directory
iptables is clearly there, I can
$ iptables --version
iptables v1.8.7 (legacy)
just fine.
This, I think, might be another thing systemd is throwing in our way, but there’s gotta be an option somewhere that’ll let us use it.
/usr/bin/iptables and /usr/sbin/iptables are both symlinks to xtables-legacy-multi in their respective directories. xtables-legacy-multi appears to be hard linked. So… I have no immediate clue why the error, I assume something with portable services.
I’ve asked the systemd-devel mailing list. If anyone knows what’s up, it’d be them.
https://lists.freedesktop.org/archives/systemd-devel/2022-October/048415.html
Neat! will check it out this evening
that was great, just worked.
1 Like
Yay! You should be able to re-run the script to update Tailscale whenever there’s a new release, too.
FYI -
I ran to update to 1.32, in order to get NextDNS working, and as you predicted it worked flawlessly. Seems like your script could be bundled into a slightly more streamlined process, I’ll take a crack at it this weekend, but fantastic work!
great catch on the issue of it not starting automatically on reboot, and boy is that a pain to debug! I finally put together that there was a race-condition between the sysext merging in the service definitions and systemd attempting to start them when sudo systemctl --state=inactive listed not found as the state for the service after a reboot. (But of course by the time we all have a console up, the overlay has happened…)
Did a little fork to collapse into a single file, tiny addition to a great job.
1 Like