term% cat index.txt CPU(1) General Commands Manual CPU(1)
NAME
cpu - connection to CPU server
SYNOPSIS
cpu [ -p ] [ -h server ] [ -u user ] [ -a auth-method ] [ -P pattern‐
file ] [ -e encryption-hash-algs ] [ -k keypattern ] [ -c cmd args ...
]
cpu [ -n ] [ -A address ] [ -R | -O ]
DESCRIPTION
Cpu starts an rc(1) running on the server machine, or the machine named
in the $cpu environment variable if there is no -h option. Rc's stan‐
dard input, output, and error files will be /dev/cons in the name space
where the cpu command was invoked. Normally, cpu is run in an rio(1)
window on a terminal, so rc output goes to that window, and input comes
from the keyboard when that window is current. Rc's current directory
is the working directory of the cpu command itself.
The name space for the new rc is an analogue of the name space where
the cpu command was invoked: it is the same except for architecture-de‐
pendent bindings such as /bin and the use of fast paths to file
servers, if available.
If a -u argument is present, cpu uses the argument as the remote user
id.
If a -c argument is present, the remainder of the command line is exe‐
cuted by rc on the server, and then cpu exits.
If a -P argument is present, the patternfile is passed to exportfs(4)
to control how much of the local name space will be exported to the re‐
mote system.
The -a command allows the user to specify the authentication mechanism
used when connecting to the remote system. The two possibilities for
auth-method are:
p9 This is the default. Authentication is done using the standard
Plan 9 mechanisms, (see authsrv(6)). No user interaction is re‐
quired.
netkey Authentication is done using challenge/response and a hand held
authenticator or the netkey program (see passwd(1)). The user
must encrypt the challenge and type the encryption back to cpu.
This is used if the local host is in a different protection do‐
main than the server or if the user wants to log into the server
as a different user.
none This skips authentication. This requires the -n flag to be spec‐
ified on the remote side.
The -e option specifies an encryption and/or hash algorithm to use for
the connection. If both are specified, they must be space separated
and comprise a single argument, so they must be quoted if in a shell
command. The default is encryption and hashing. See ssl(3) for de‐
tails on possible algorithms. The argument specifies no encryption al‐
gorithm and can be used to talk to older versions of the cpu service.
The -k flag specifies a key pattern to use to restrict the keys se‐
lected by the auth_proxy call used for authentication.
The name space is built by running /usr/$user/lib/profile with the root
of the invoking name space bound to /mnt/term. The service environment
variable is set to cpu; the cputype and objtype environment variables
reflect the server's architecture.
The -R flag causes cpu to run the server (remote) side of the protocol.
It is run from service files such as /bin/service/tcp17010. The -O
flag is similar but simulates the pre-9P2000 version of the cpu proto‐
col. The -n option allows using the none authentication method for in‐
coming connections and must be specified before the -R and -O flags.
The -p flag pushes the aan(8) filter onto the connection to protect
against temporary network outages.
The -A flag sets the announce-string address to use for aan(8) connec‐
tions, if requested by the initial protocol.
FILES
The name space of the terminal side of the cpu command is mounted, via
exportfs(4), on the CPU side on directory /mnt/term. The files such as
/dev/cons are bound to their standard locations from there.
SOURCE
/sys/src/cmd/cpu.c
SEE ALSO
rc(1), rio(1), exportfs(4), aan(8)
BUGS
Binds and mounts done after the terminal lib/profile is run are not re‐
flected in the new name space.
By default, the entire namespace of the local system is exported to the
remote system. Use of the -P option in conjunction with a customized
patternfile can limit this exposure, but also limits the usefulness of
/mnt/term.
CPU(1)