Bluish Coder

Inferno OS provides a mechanism to connect to remote computers and execute commands similar to the way SSH works on Unix systems. The command to do this is cpu. This can be used to execute commands, start a remote shell, and share GUI applications.

To use cpu you'll need to set up authentication and encryption. This provides the mechanism to authentiate to the remote machine and encrypt the session data.

The rstyx command needs to be run on the remote host to start the services that cpu uses to connect:

; ndb/cs
; ndb/dns
; svc/rstyx

The ndb commands shown there start the services to use the network and DNS. Usually this is started beforehand but I list them for completeness.

With rstyx running and authentication configured the client can connect to the remote machine using cpu:

% cpu example.com
; ...now on server...

This creates a session that is encrypted during authentication but then unencrypted. To use an encrypted session the -C flag is required:

% cpu -C rc4_256 example.com
; ls
; ...server directory listing...

cpu takes an optional argument, that defaults to the shell, to execute:

% cpu -C rc4_256 example.com ls
; ...server directory listing...
%

The namespaces available to the cpu command are mapped to the directory /n/client/ in a cpu session. This means the remote shell or command can use resources on the client. For example a phone running Inferno can cpu to a remote host and that remote host can make calls, send messages, etc using the phones resources. By controlling what namespaces exist before cpu is called the client can restrict what resources are available in the remote session.

Another example of resource sharing is to run GUI programs on the server but have the display appear on the client, similar to how X11 forwarding operates. Doing this requires having the wm window mananger on the client export its interface to a namespace (it's one of the few applications that doesn't do this by default on Inferno) and then in the cpu session bind that to a location that GUI programs can see. On the client the export would look like:

; mount {wmexport} /mnt/wm
; cpu -C rc4_256 example.com
; wmimport -w /n/client/mnt/wm acme &

This runs the editor acme on the server but the display is shown on the client. The -w flag passed to wmimport gives the path to an exported directory provided by wmexport. In this case we use the directory exported on the client which cpu has exposed under /n/client/mnt/wm.

Any graphical program can be run this way including GUI shells, games, etc. Unfortunately, like X11 forwarding, it's fairly slow over low bandwidth connections. For local connections it's quite usable however. This could be a useful way to share a phone application on a desktop or a desktop application on a phone when it's connected to the same network.

A combination of resources on the remote server and the client can be used to work around the low bandwidth issue. The acme editor exposes directories and files to control the editor. By running acme on the client, cpu-ing to the remote server so it can see these directories, the programs on the remote end can send data to the client acme window. An example follows:

; acme
; ...create a terminal in acme by 2nd-button clicking `win`...
; ...in the acme terminal window...
; cpu -C rc4_256 cd.pn

Now the remote session running inside acme will expose the needed interfaces to control the client acme program via /n/client/mnt/acme:

; echo Hello >/n/client/mnt/acme/new/body

This command, executed on the server in the remote session, creates a new window in the client acme program with the text "Hello".