adyanth / openwrt-tailscale-enabler

Brings Tailscale to low powered OpenWRT devices
MIT License
1.2k stars 185 forks source link

Better way to auto-update? #14

Closed slhck closed 2 years ago

slhck commented 3 years ago

I am not sure how auto-update is supposed to work.

The /usr/bin/tailscale file checks for the existence of /tmp/tailscale, and only if that one does not exist, it will attempt a download and update. So in any case, an update will only work if those files in tmp are removed entirely before running /usr/bin/tailscale again.

Even then, having to manually edit the file seems a bit hacky.

Can you please clarify how the update procedure should work under normal circumstances?

adyanth commented 3 years ago

Hey @slhck the autoupdate is meant to check at the next reboot. (/tmp does not persist on reboots, ramfs/tmpfs)

If you want to upgrade in place, it can be done. Stop the service using /etc/init.d/tailscale stop, kill any running tailscaled processes, rm -f /tmp/tailscale* and then start the service back using /etc/init.d/tailscale start. Should download the new one.

Did you have any ideas on how it could be better achieved?

slhck commented 3 years ago

Thanks for the explanation.

I guess rebooting is not a common task — for me at least.

Do you know if it is possible to update in-place like the Ubuntu packages for Tailscale are doing it? Automatically reinstating the connection, that is.

I don't have an easy solution for the time being. Ideally the new binaries would be downloaded asynchronously and replaced after being extracted, then triggering a restart of the service.

adyanth commented 3 years ago

A service restart should still reconnect you to the network. Maybe the init system can handle the upgrades using an upgrade command? Not sure, need to explore.

slhck commented 3 years ago

I looked into the Ubuntu packages and it seems that all that is done is reloading the service in the postinst file:

if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
    deb-systemd-helper unmask 'tailscaled.service' >/dev/null || true
    if deb-systemd-helper --quiet was-enabled 'tailscaled.service'; then
        deb-systemd-helper enable 'tailscaled.service' >/dev/null || true
    else
        deb-systemd-helper update-state 'tailscaled.service' >/dev/null || true
    fi

    if [ -d /run/systemd/system ]; then
        systemctl --system daemon-reload >/dev/null || true
        deb-systemd-invoke start 'tailscaled.service' >/dev/null || true
    fi
fi

The systemd service itself has a cleanup action in addition to what you have in your package now; not sure if that is needed:

[Unit]
Description=Tailscale node agent
Documentation=https://tailscale.com/kb/
Wants=network-pre.target
After=network-pre.target NetworkManager.service systemd-resolved.service

[Service]
EnvironmentFile=/etc/default/tailscaled
ExecStartPre=/usr/sbin/tailscaled --cleanup
ExecStart=/usr/sbin/tailscaled --state=/var/lib/tailscale/tailscaled.state --socket=/run/tailscale/tailscaled.sock --port $PORT $FLAGS
ExecStopPost=/usr/sbin/tailscaled --cleanup

Restart=on-failure

RuntimeDirectory=tailscale
RuntimeDirectoryMode=0755
StateDirectory=tailscale
StateDirectoryMode=0700
CacheDirectory=tailscale
CacheDirectoryMode=0750
Type=notify

[Install]
WantedBy=multi-user.target

But the tailscale client can't be restarted so easily, right? I wonder how that is done.

adyanth commented 3 years ago

The postinst makes extensive use of systemd specific stuff which wont work in openwrt's init system. Translating this is the main task.

tailscale client is a run and die binary. Just deleting the /tmp/tailscale file causes the next download to use the latest binary available. The tailscaled is the only one that needs action since it runs as a daemon.