mote command

Mote is a command-line tool that enables interaction with remote machines, primarily used for running cross-compiled Go tests. It supports various connection methods, including SSH, Gomote, TCP over Tailscale, and authenticated direct TCP. To initiate a connection, mote requires a host URL, such as ssh://kremvax, which denotes the server to be connected.

For running cross-compiled Go binaries, mote treats the command name as a file to be uploaded when it contains a slash. For instance, "./helloworld" is uploaded, while "hostname" is not. The name resolves to a file in the same manner as running it locally, resulting in a remote temporary directory that includes the local directory name.

The repeatable -u flag allows the upload of additional files or directories into the remote temporary directory tree. For instance, if a test binary necessitates testdata, the -t flag can upload testdata, ../testdata, and ../../testdata, up to the current Go module root.

The "mote alias" command enables the creation of aliases for URLs, which are subsequently used when executing mote commands. Upon execution, mote automatically determines the GOOS and GOARCH of the remote system. If an alias corresponding to the specific GOOS-GOARCH duo does not exist, mote automatically generates one. When the "@server" is omitted, mote attempts three fallback methods in sequence.

Go toolchain facilitates "go run" and "go test" of cross-compiled binaries by searching for a runner named go_$GOOS_$GOARCH_exec within the shell path. To create runner scripts for all GOOS-GOARCH combinations lacking one, the user can execute "mote -t" on the arguments. The script omits the server specification, prompting mote to utilize the aforementioned fallbacks.

Cross-compilation on the command line sets $GOOS and $GOARCH in the environment that "go test" subsequently passes to the script, thus selecting the appropriate alias for the target system. By setting $MOTE, users can override this selection for a single command, specifying either an alias or a URL to employ instead. This feature proves beneficial when multiple servers operate using the identical $GOOS-$GOARCH.

To employ mote over SSH, both the client and server must have mote compiled and installed, with mote being accessible on the server's PATH. It is crucial that mote communicates with the server via an accessible connection; the Tailscale library negates this necessity. Upon the initial client or server use of Tailscale, authentication is required.

Users must generate an auth key by accessing the "Keys" page within the Tailscale admin console (https://login.tailscale.com/admin/settings/keys), clicking "Generate auth key," and caching the credentials for future use. The authentication key must be tagged with "tag:mote" in the tailnet policy file's "tagOwners" section before generation.

Once generated, mote registers with the tag "tag:mote," creating mote-servername on the server and mote-clientname on the client, where clientname corresponds to the first element of the local host name. To alter the client name, run "mote login tail://clientname." Each machine registers only a single node; if already logged in via "mote login" or "mote serve," mote utilizes the existing login rather than registering anew.

Following registration, "mote serve tail://" can be shortened to "mote serve tail:". The Tailscale node stays operational in the background as a daemon, similar to how ssh maintains a connection. The first mote requiring the tailnet initiates the daemon; subsequent ones locate and reuse it, ensuring only the first command incurs the connection cost.

The daemon terminates after 30 minutes without tasks. For direct TCP connections, the URL format is tcp://host:port. Clients and servers share a password, which authenticates the connection and establishes an encrypted conversation. Running "mote login URL" prompts for the password, saving it for future use. Each machine stores the password under the utilized URL, enabling both client and server to name the same server differently.

The server authenticates using the URL it serves and then serves accordingly. The host can be omitted (tcp://:port) to signify listening on all interfaces. Each server possesses a unique password; logging in to a second server adds an entry rather than replacing the initial one. The Go project maintains a custom remote execution facility referred to as gomotes, which provide access to the various builders utilized for Go's testing.

If the gomote command is present on the PATH, mote can leverage these servers. In cases where gomote is not recently used, one may need to execute "gomote login" prior to use.