Re: Setting up a VPN daemon as a Portable Service

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The problem wasn't mounting the system extension automatically. That worked just fine. It was that systemd would try to start the service before the system extension mounted, which would fail, for obvious reasons. This weekend I think I'm going to try the BindReadOnlyPaths option and see if I can get that to work.

On Fri, Oct 7, 2022 at 3:35 PM David Anderson <dave@xxxxxxxxxxx> wrote:
Yeah, so far we (tailscale) haven't found a good way to run on the Steam Deck at bootup, and also survive the A/B OS updates. Systemd system extensions _can_ be activated during bootup, if you place the extension in one of the well-known locations (/var/lib/extensions would be the one to use on Deck, as iirc it survives A/B upgrades), and the systemd-sysext service is enabled.

I would check if systemd-sysext.service is enabled on the deck, and if not, file a request with Valve to enable that service in a future update. You should present it as enabling further customization of their platform.

Another possible reason that sysexts aren't working for you, is that the Deck's /etc/os-release doesn't define a SYSEXT_LEVEL, and the VERSION_ID changes with every OS update. Because of this, the system extension will refuse to activate after every update (either SYSEXT_LEVEL or VERSION_ID must match exactly), until you rebuild a new image with the right OS metadata. Asking Valve to set SYSEXT_LEVEL to a stable value would make it even easier to provide Deck OS extensions reliably :)

- Dave

On Thu, Oct 6, 2022, at 12:08, Arian van Putten wrote:
Afaik Portable services run in an isolated root and dont have access to the hosts rootfs.  You'd have go include iptables and all its dependencies in the portable services directory. If you don't want to do that you'd have to use BindReadOnlyPaths= to give the service access to the required host paths or you'd have to use a system extension.

That's probably why they advice running as a system extension. 

I think there are mechanisms for setting up system extensions on startup but I'm not familiar enough with the details. Maybe someone else in the list knows.




On Thu, 6 Oct 2022, 20:21 Duncan Gibson, <legowerewolf@xxxxxxxxx> wrote:
Hi, everyone.

The high-level overview: I'm trying to install Tailscale as a portable service on my Steam Deck.

Tailscale is a point-to-point VPN service, essentially a wrapper around Wireguard that helps with network setup and management. The Steam Deck is Valve's handheld PC running SteamOS 3, which is derived from Arch. It uses an A/B partition system for system files, meaning you can't install a service the normal way.

There is a guide to do this, posted on their own blog, but it uses system extensions which aren't good for services that you want to run on startup. Indeed, following that guide puts me in a state where I have to manually start the daemon every time I reboot my Deck, even with the service enabled.

Let's move on to how I've started to do this.

Tailscale is available through most package managers, but they also publish static binaries with systemd unit files.

This script grabs that binary, extracts it, and moves it into a portable service directory structure.

# 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/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

Not automated yet is patching the provided unit file - you need to remove the EnvironmentFile line and "--port $PORT $FLAGS" options, and add
[Exec]
Environment="PATH=/usr/bin"

Attach the portable service: sudo portablectl attach ./tailscaled --profile="">
and try starting it: sudo systemctl start tailscaled

It fails, leaving this in the logs:

logtail started
Program starting: v1.30.2-t24c524c78-gc399ae6fa, Go 1.19.1-tsb13188dd36: []string{"/usr/sbin/tailscaled", "--state=/var/lib/tailscale/tailscaled.state", "--socket=/run/tailscale/tailscaled.sock"}
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, in fact, at /usr/bin/iptables, so what am I missing? Before I added the Environment line, I was getting errors that iptables wasn't on the PATH, so I suspect that now tailscaled can see iptables, but systemd isn't letting tailscaled run it.

Thanks for having a look at this.



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux