Add plugins support

[damdo]

As part of the update system efforts, we are introducing the ability to specify plugins that allow to push and pull updates from many different sources (e.g. OCI, S3, ...) in addition to the natively supported HTTP file server source.

As such in gokrazy/gokrazy#173 we want to give selfupdate the ability to understand payload links that differ from HTTP and may be coming from a GUS update response.

To be able to do this, selfupdate must give the user the ability to specify a plugin name (which will be used by selfupdate to reference the plugin binary) and some credentials that the plugin will use to fetch the update from the source registries (think for example at the credentials necessary to fetch an OCI update payload from an OCI registry or at the AWS credentials necessary to pull a file from AWS S3).

This PR aims at implementing this ability for selfupdate.

Note:
With this approach selfupdate will be able to load only one plugin at a time in addition to the already natively supported HTTP fetching mechanism.

[damdo]

This one will need some thought

[stapelberg]

Hmm, why will selfupdate not SIGTERM cleanly in this state? I would have expected it to. SIGINT and SIGTERM are hooked up to context cancellation in selfupdate’s main function.

[damdo]

The problem here is that the Reboot() is blocking:

• target.Reboot() calls
• the /reboot http endpoint:
  https://github.com/gokrazy/gokrazy/blob/8916805aa0c7fad3597670de2afd35c48f10f06c/update.go#L333-L365 that calls
• the killSupervisedServicesAndUmountPerm(signalDelay) func (here) that calls
• the killSupervisedServices() func (here)
• the killSupervisedServices (here) then issues the SIGTERM to all the processes (including selfupdate), and waits for them to terminate. If they don't terminate cleanly, it issues a SIGKILL to all of them after signalDelay (100s), including for selfupdate.
• So basically selfupdate is blocked on target.Reboot(), which in turn is blocked on the selfupdate process to exit cleanly, which won't because is waiting on target.Reboot().

As such I can think of two options here:

1. either we make selfupdate exit cleanly on SIGTERM by adding a ctx to cancel the target.Reboot() call
2. or we add a target.AsyncReboot(), to call in this selfupdate case, that passes an async=true arg to the /reboot HTTP call, which acks the /reboot HTTP API call as 200 and runs the killSupervisedServicesAndUmountPerm async in a separate goroutine, which should avoid the waiting

WDYT?

[stapelberg]

I think handling target.Reboot getting interrupted by SIGTERM is the better option here, as it seems simpler and does not require increasing the API surface.

[damdo]

Ok cool, created a PR for that here: gokrazy/updater#2

[stapelberg]

Actually, I just noticed that there is another case where the blocking behavior of /reboot gets in the way: when updating gokrazy via Caddy (e.g. for using Tailscale for authentication, see gokrazy/gokrazy#257), we’ll also encounter an error, and a timeout.

Maybe we should give the asynchronous reboot a try. Do we need another parameter for that or could we just change how reboot works? Did you experiment with that?

(We can still introduce a context to gokrazy/updater independently.)

[damdo]

Yes let's give it a go, see it implemented here:

• Add optional async argument to /reboot & /poweroff gokrazy#319
• Add async option to the Reboot method updater#3

[damdo]

Changing this so then we get an immediate first check without waiting an extra frequency interval.

Also changing the skipWaiting to only skip the Jitter once, the first time.

These two changes combined still achieve the same initially defined behaviour for skipWaiting, but improve the first check also in cases where skipWaiting is set to false