About
RSS

u9cpu


One nice feature of drawterm and Plan9's cpu and ncpu is that parts of the local filesystem appear on the remote machine as /mnt/term.

So instead of

  1. ssh hostname
  2. dang, forgot that file
  3. open local shell in new tmux/xterm/screen
  4. scp file hostname:
  5. back to the shell with ssh hostname
  6. do stuff on hostname
  7. dang another file not there
  8. back to the shell with the scp
  9. scp anotherfile hostname:
one can simply do
  1. drawterm hostname
  2. cp /mnt/term/file .
  3. do stuff on hostname
  4. cp /mnt/term/anotherfile .

Can we do that over ssh, too?
One could try diverse trickery with sftp through FUSE, or NFS/CIFS/WhateverFS exports.

I explored the following path closer to the Plan9 original:
Unix-like systems can run u9fs to export directories over 9p, and 9pfs to mount them. Forwarding u9fs's in/output through ssh caused strange errors. Using socat to bind the filedescriptors to a TCP socket on localhost and forwarding that through ssh works.
The result is u9cpu.sh, which mounts a given directory (default $HOME/tmp) as /mnt/term on the remote machine and then opens a shell there.

UPDATE Ron Minnich of Plan9 fame has implemented something similiar in Go: u-root/cpu.

Tue, 15 Feb 2022
[/plan9] permanent link

Remote Boot and Root for Plan9


Started to play with Plan9 again. First major experiment: Run a bare-metal cpu server without local disks. All configuration can be done from an OpenBSD server supplying the loader, kernel, bootup-config, and filesystem. The Plan9 server runs on an old 1U Pentium 4 server.

Results so far: PXE finds Plan9 loader, that again loads a plan9.ini by TFTP which specifies a kernel, which then mounts its rootfs from a u9fs on OpenBSD. Said rootfs contains cpurc which determines the server's behaviour.

Details

dhcpd.conf on DHCP/TFTP server: 

host cpu {
        hardware ethernet 00:11:22:33:44:55;
		fixed-address 192.168.66.99;
		filename "9pxeload";
}

Once the PXE Plan9 bootloader 9pxeload is running it pulls the file /cfg/pxe/001122334455 from the DHCP/TFTP server. This file is used as the plan9.ini.

Example plan9.ini: 


bootfile=ether0!9pccpu
bootargs=tcp!192.168.66.11!564
nobootprompt=tcp!192.168.66.11!564
fs=192.168.66.11
console=0 b19200 pn

9pxeload will load 9pccpu from the TFTP server it found on ether0 and supply that kernel with the infomation that its rootfs will be remotely supplied from 192.168.66.11. Console is on first serial interface with 19200bps and no parity.

On 192.168.66.11 the following entry in inetd.conf starts 9legacy's modified u9fs process on demand: 

9fs stream tcp nowait root /mnt/9atom/unix/u9fs u9fs -a none /mnt/9atom

(This implies that the service 9fs is already defined as 567 in /etc/services.)
The u9fs exports The original u9fs found in /sys/src/cmd/unix/u9fs.c exported the whole fs of the server. This led to the custom of chrooting the process, with all the pitfalls included. The 9legacy patch allows to export arbitrary subtrees. the filetree under /mnt/9atom without authorization. This is excusable only in a private network and necessary only because my rootless cpu server does not know the password for the remote fs. A way around that would be to put the password into the kernel itself (which again is totally insecure in an open network where everybody can fake the MAC and pull the kernel...)

The Plan9 server can now be controlled completely from the OpenBSD machine which is nice for testing configurations.

Thu, 11 Apr 2013
[/plan9] permanent link

The ubiquitous fs in Plan9


The terms file server, file system and the abbreviation fs appear a lot in Plan9 documentation. For example, there are the manpages fs(3), fs(4), fs(8), and kfs(4).

First fs(4) aka Ken's FS. This was a file server inside the kernel which required a specially built kernel and was used together with a dedicated CPU server and many terminals. It is not part of the kernel sources any more, but its manpage lives on. To add confusion, there is also a manpage fs(8) for the console of Ken's fs.

Then there is kfs(4), a file system for terminals. It is implemented in user-space. No relation to Ken's FS besides the name. Strangely there seems to be no option to repair a broken kfs:

If the file system is inconsistent, the user is asked for permission to ream (q.v.) the disk.

(reaming means deleting). kfs cannot be managed by a console like Ken's fs and fossil, but by options to an executable kfscmd. UPDATE kfscmd has commands to repair a broken kfs.

As another example for the non-injectivity of abbreviations, there's fs(3) which is not a file system at all, but a kind of soft-raid that allows concatenation, striping and (simple) mirroring of files, e.g. disks.

On the fourth hand, there is fossil. This is the current default for CPU and File servers. It can be configured to move its blocks to an archival storage server venti. It is managed with its own console fossilcons which attaches itself not as /srv/fossilcons but /srv/fscons.

Wed, 09 Jul 2008
[/plan9] permanent link

Plan9


Plan9 is an operating system by the authors of the original Unix, with integrated support for distributed applications.

Plan9 has its own windowing system, rio, quite different from X11.

It is possible to connect to Plan9 machines by drawterm from Unix machines running X11. drawterm starts the windowing system on the remote Plan9 and everything works as if sitting in front of it.

While typing from one machine I remembered I had already solved a problem in a one-liner, but on a different drawterm which ran on a Unix box miles away.

cpu% echo $wsys
/srv/rio.myname.1234
cpu% lc /srv/rio.*
rio.myname.1234		rio.myname.5678

So the other drawterm runs the rio mounted on /srv/rio.myname.5678. To get at the scrollback of a window displayed on a screen on a totally different machine: 

cpu% mount /srv/rio.myname.5678 /n/wsys 1
cpu% cat /n/wsys/text 
[...lines of output...]
[...including the one-liner...]

Wed, 27 Jun 2007
[/plan9] permanent link