os-tailscale peer relay option

[hyperboly]

This PR adds peer relay option to os-tailscale.

Creates a field for peer relay port, if 0 peer relay is disabled.

Related: #5122

[hyperboly]

tailscale up won't accept --relay-server-port as an arg, only tailscale set. Working on adding tailscale set to the plugin.

[sheridans]

The --relay-server-port flag itself is defined in:
https://raw.githubusercontent.com/tailscale/tailscale/refs/heads/main/cmd/tailscale/cli/ssh.go

Specifically:

setf.StringVar(&setArgs.relayServerPort, "relay-server-port", "", "UDP port number (0 will pick a random unused port) for the relay server to bind to, on all interfaces, or empty string to disable relay server functionality")

Later in the same file, non-empty values get parsed an assigned:

if setArgs.relayServerPort != "" {
	uport, err := strconv.ParseUint(setArgs.relayServerPort, 10, 16)
	if err != nil {
		return fmt.Errorf("failed to set relay server port: %v", err)
	}
	maskedPrefs.Prefs.RelayServerPort = ptr.To(uint16(uport))
}

This would change the default expected behaviour of Tailscale:

• Required field, set to 0 by default to disable later in rc template. Tailscale uses a value of 0to use a random port and an empty string value to disable
• Prevents the user from specifying a port value of 0 to use a random port.

@fichtner unless I am wrong shouldn't be a required field, should be empty by default, allowed values 0-65535? Template logic would also need adjusting, and if supported flag for tailscale up args.

[hyperboly]

@sheridans I think the link you mean is https://github.com/tailscale/tailscale/raw/refs/heads/main/cmd/tailscale/cli/set.go

You're right the value can't be 0 for disabling it needs to be unset. For the implementation to work, the plugin would need to support tailscale set and run the command after the service starts.

I'm not sure how to do this, is there a reference plugin I can take a look at?

[sheridans]

If you you do it manually via the command line does the plugin still work and does the setting persist?

Up args handling is a bit wierd, if they changed and tailscale was restarted without the same up args as previously it threw an error and wouldn't start.

[hyperboly]

No, master branch os-tailscale doesn't persist tailscale set options. Maybe the service file has to include a script that runs after tailscale up? With systemd it might look like ExecStart=command ... && tailscale set ....