sys/man/1/cpu

   1 .TH CPU 1
   2 .SH NAME
   3 cpu \- connection to CPU server
   4 .SH SYNOPSIS
   5 .B cpu
   6 [
   7 .B -p
   8 ] [
   9 .B -h
  10 .I server
  11 ] [
  12 .B -u
  13 .I user
  14 ] [
  15 .B -a
  16 .I auth-method
  17 ] [
  18 .B -P
  19 .I patternfile
  20 ] [
  21 .B -e
  22 .I encryption-hash-algs
  23 ] [
  24 .B -k
  25 .I keypattern
  26 ] [
  27 .B -c
  28 .I cmd args ...
  29 ]
  30 .PP
  31 .B cpu
  32 [
  33 .B -n
  34 ] [
  35 .B -A
  36 .I address
  37 ] [
  38 .B -R
  39 |
  40 .B -O
  41 ]
  42 .SH DESCRIPTION
  43 .I Cpu
  44 starts an
  45 .IR rc (1)
  46 running on the
  47 .I server
  48 machine, or the machine named in the
  49 .B $cpu
  50 environment variable if there is no
  51 .B -h
  52 option.
  53 .IR Rc 's
  54 standard input, output, and error files will be
  55 .B /dev/cons
  56 in the name space where the
  57 .I cpu
  58 command was invoked.
  59 Normally,
  60 .I cpu
  61 is run in an
  62 .IR rio (1)
  63 window on a terminal, so
  64 .IR rc
  65 output goes to that window, and input comes from the keyboard
  66 when that window is current.
  67 .IR Rc 's
  68 current directory is
  69 the working directory of the
  70 .I cpu
  71 command itself.
  72 .PP
  73 The name space for the new
  74 .I rc
  75 is an analogue of the name space where the
  76 .I cpu
  77 command was invoked:
  78 it is the same except for architecture-dependent bindings such as
  79 .B /bin
  80 and the use of fast paths to file servers, if available.
  81 .PP
  82 If a
  83 .B -u
  84 argument is present,
  85 .I cpu
  86 uses the argument as the remote user id.
  87 .PP
  88 If a
  89 .B -c
  90 argument is present, the remainder of the command line is executed by
  91 .I rc
  92 on the server, and then
  93 .I cpu
  94 exits.
  95 .PP
  96 If a
  97 .B -P
  98 argument is present, the
  99 .I patternfile
 100 is passed to
 101 .IR exportfs (4)
 102 to control how much of the local name space will be exported to
 103 the remote system.
 104 .PP
 105 The
 106 .B -a
 107 command allows the user to specify the authentication mechanism used
 108 when connecting to the remote system.  The two possibilities for
 109 .I auth-method
 110 are:
 111 .TF netkey
 112 .TP
 113 .B p9
 114 This is the default.  Authentication is done using the standard Plan 9
 115 mechanisms, (see
 116 .IR authsrv (6)).
 117 No user interaction is required.
 118 .TP
 119 .B netkey
 120 Authentication is done using challenge/response and a hand held
 121 authenticator or the
 122 .I netkey
 123 program
 124 (see
 125 .IR passwd (1)).
 126 The user must encrypt the challenge and type the encryption
 127 back to
 128 .IR cpu .
 129 This is used if the local host is in a different protection domain than
 130 the server or if the user wants to log into the server as a different
 131 user.
 132 .TP
 133 .B none
 134 This skips authentication. This requires the
 135 .IR -n
 136 flag to be specified on the remote side.
 137 .PD
 138 .PP
 139 The
 140 .B -e
 141 option specifies an encryption and/or hash algorithm to
 142 use for the connection.  If both are specified, they must
 143 be space separated and comprise a single argument, so they
 144 must be quoted if in a shell command.  The default is
 145 .L rc4_256
 146 encryption and
 147 .L sha1
 148 hashing.  See
 149 .IR ssl (3)
 150 for details on possible algorithms.  The argument
 151 .L clear
 152 specifies no encryption algorithm and can be used to talk
 153 to older versions of the
 154 .I cpu
 155 service.
 156 .PP
 157 The
 158 .B -k
 159 flag specifies a key pattern to use to restrict the keys
 160 selected by the
 161 .I auth_proxy
 162 call used for authentication.
 163 .PP
 164 The name space is built by running
 165 .B /usr/$user/lib/profile
 166 with the root of the invoking name space bound to
 167 .BR /mnt/term .
 168 The
 169 .B service
 170 environment variable is set to
 171 .BR cpu ;
 172 the
 173 .B cputype
 174 and
 175 .B objtype
 176 environment variables reflect the server's architecture.
 177 .PP
 178 The
 179 .B -R
 180 flag causes
 181 .I cpu
 182 to run the server (remote) side of the protocol.
 183 It is run from service files such as
 184 .BR /bin/service/tcp17010 .
 185 The
 186 .B -O
 187 flag is similar but simulates the pre-9P2000 version
 188 of the
 189 .I cpu
 190 protocol.
 191 The
 192 .B -n
 193 option allows using the
 194 .B none
 195 authentication method for incoming connections and must be
 196 specified before the
 197 .B -R
 198 and
 199 .B -O
 200 flags.
 201 .PP
 202 The
 203 .B -p
 204 flag pushes the
 205 .IR aan (8)
 206 filter onto the connection to protect against temporary
 207 network outages.
 208 .PP
 209 The
 210 .B -A
 211 flag sets the announce-string
 212 .I address
 213 to use for
 214 .IR aan (8)
 215 connections, if requested by the initial protocol.
 216 .SH FILES
 217 The name space of the terminal side of the
 218 .I cpu
 219 command is mounted, via
 220 .IR exportfs (4),
 221 on the CPU side on directory
 222 .BR /mnt/term .
 223 The files such as
 224 .B /dev/cons
 225 are bound to their standard locations from there.
 226 .SH SOURCE
 227 .B /sys/src/cmd/cpu.c
 228 .SH SEE ALSO
 229 .IR rc (1) ,
 230 .IR rio (1) ,
 231 .IR exportfs (4) ,
 232 .IR aan (8)
 233 .SH BUGS
 234 Binds and mounts done after the terminal
 235 .B lib/profile
 236 is run are not reflected in the new name space.
 237 .PP
 238 By default, the entire namespace of the local system is
 239 exported to the remote system. Use of the
 240 .B -P
 241 option in conjunction with a customized patternfile can
 242 limit this exposure, but also limits the usefulness of
 243 .B /mnt/term.