Think Tank Workspaces


9front kind of made this easy for everyone. The only thing you have to do is edit /n/9fat/plan.ini and add service=cpu to the very end of the file then reboot. Everything should just work fine without too much effort. This is also where all of the problems begin. So let's jump into it.

On your system if you have performed inst/start and managed to get the system up and running and logged in as glenda with the GUI of rio up and running. You have full access to ediors such as sam and acme. This makes life much easier. If you plan to stick with plan9 you need to know a couple of commands in 'ed' editor to get things working or at the very least allow you to remove 'service=cpu' and boot back up into GUI mode.

So why do you want a CPU-Authentication server running in the first place? Well chances are you are not running bare metal and opted for qemu or virtualbox or something similar. Using the gui in virtualization is a bit slow and cumbersome. Drawterm and rcpu will allow you to authenticate and have full access efficiently while using another operating system. Think of drawterm as VNC on steroids and super efficient and fast.

crash course using 'ed' editor

Hello world I hope this works
blah blah
w foo.txt

So you can invoke ed by itself or with a filename such as: ed foo.txt

a to add new lines

p is the current line

n gives you the number


ed foo.txt
hello world I hope this works
2 blah blah
hello world I hope this works
hi world I hope this
cpu% cat foo.txt
hi world I hope this
blah blah

. dot is required on a line by itself to signify the end of writing or chaning

w write data

q to exist out of program

There are other commands but these are the basics and will allow you to make changes quckly without too much trouble.

First steps

  1. setup network database
  2. edit plan9.ini to boot as a server
  3. setup nvram
  4. write to nvram
  5. add user to auth
  6. add user to file system


edit /lib/ndb/local

Here is my example.

ip= sys=localhost dom=localhost
# example: adjust to fit your network
auth=cirno authdom=yoda # i feel like this should stay
ipnet=yoda ip= ipmask=
ip= sys=cirno dom=cirno.thinktank ether=0800270312de
ip= sys=ghob dom=ghob.thinktankworkspaces

So I probably should pick a different name than the default 'cirno' but that didn't exactly matter to me at the moment.

This is on a virtual box and the only thing that mattered is the sys cirno ip address and that other things reflected such as auth, cpu and fs. My virtual box is using a bridge adapter on the wifi network.

Also notice I didn't use a full domain name for cirno.thinktank. The only domain that I have that resolves in this example is

Here is another example using qemu on AWS ec2.

auth=ghob authdom=thinktankworkspaces
ipnet=thinktankworkspaces ip= ipmask=
ip= sys=ghob dom=thinktankworkspaces ether=525400123456
ip= sys=www

So while the internal network is 10.0.2.x everything works fine because of the port forwarding i'm using and qemu is using the external network inerface for

/lib/ndb/local is basically a file filled with tuples. I guess its plan9's cheap way of using a database. Read more at 'man ndb(8)'


I don't usually set nvram in plan9.ini because it generally just works. But it helps to be explicit. To access plan9.ini you need to run the following command.

9fs 9fat

You can navigate to /n/9fat and list the contents of the files in that directory.

cpu% ls

The system only reads plan9.ini but I have different configurations that I can simply copy over and run without having to use the 'ed' editor.

bootargs=local!/dev/sdC0/fscache -a tcp!*!564

Notice the nvram line. This should match the same drive as the bootargs /dev/sdC0 for you it might be a different dirve letter like /dev/sdE1. This depends where you installed things at the time of installation. Here is an example of the plan9.ini I have installed on AWS ec2

bootargs=local!/dev/sdC0/fscache -a tcp!*!564

Notice I have other features like mouseport=ask. It will never be used in this config because its a cpu server but you can always force the system to ask what you want. It is possoble to run rio on a cpu but its a bit tricky and beyond the scope of this document. Also notice console=0. Since its on an EC2 if have a lot of limitations regarding fonts and frame buffers and video settings. I'm explicitly forcing this to be console only text mode.

For more information you can read the man page plan9.ini(8)

man plan9.ini

Also notice tcp!*!564. We kind of need this running so we can authenticate and log in using other tools like drawterm and rcpu etc...The asterisk just means let every source address in.

hjfs syntax is slightly different:

bootargs=local!/dev/sdXX/fs -m 702 -A -a tcp!*!564


After you have configured plan9.ini and run 'fshalt -r' to reboot the first thing that is going to happen is a bad nvram key will appear and force you to authenticate or with 9front I think it just jumps right into authentication. Here is an example of the older system

bad nvram key
bad authentication id
bad authentication domain
authid: <glenda>
autdom: <9front> or whatever you called it 
secstore key:
password: [glenda's password]

You can force this command by running: auth/wrkey

cpu% auth/wrkey
authid: glenda
authdom: yoda
secstore key: [blank hit enter]
password: for glenda

So why would you run auth/wrkey. Well more often then not I forget the password. But really you could also change the user that boots the system. I suggest you read about how to do that before changing out user glenda, because you will have to edit another fila /lib/ndb/auth. But lets ignore that for now.

The user that bootes the system is admin of that computer. A lot of power through physical access. But there is more to that. The system that has been booted, the authentication, mechanism and the file server are all different parts.

To add the user to the autheentication system you need to run 'auth/keyfs'

cpu% auth/keyfs
auth/changeuser glenda
Password: same as glenda
Confirm password: same as glenda
Assign inferno: n
Defaults for the rest or just hit enter

Next you need to add the user to the File system.

Glenda is automatically added during install.

echo newuser william >> /srv/cwfs.cmd
echo newuser upas +william >> /srv/cwfs.cmd

you can add 'william' to sys and adm if you really need to.

At this point you should be able to log into the system remotely.


you can find it at

You can download drawterm.exe for windows or get the source code and compile it on your system.

It compiles fine on Mac.

install drawterm from source.

git clone git:// cd plan9front/drawterm

To build on Unix, run CONF=unix make.
To build on FreeBSD, run CONF=freebsd make.
To build on OpenBSD, run CONF=openbsd make.
To build on Solaris using Sun cc, run CONF=sun make.
To build on Windows, you can use Visual C or Mingw on cygwin.
To build on Mac OS X with X11 (xquartz), run CONF=osx-x11 make.
To build on Mac OS X with Cocoa, run CONF=osx-cocoa make and “cp drawterm gui-cocoa/”.

I usually run it command line as follows:

plan9front/drawterm-908xxxxxx/gui-cocoa/ -a -h -u glenda

rcpu errors

If you are connecting from another plan9 system you can type the following:

rcpu -u glenda -h

Keep in mind you are doing this from another system. So its possible you might get the following error:

/bin/tlsclient: auth_proxy: auth_proxy rpc write: no key matches
proto=p9sk1 dom=yoda role-client user=glenda !password?

This can be super frustrating. It happens when you are dealing with two different authentication servers so sometimes you need to run


then retry the 'rcpu' command again.

Here is another problem I run into a lot.

tlsclient: auth_proxy: auth_proxy rpc write: cs: can't translate address:
dns: name does not exist

You know you can connect to it and you know the remote location is setup correctly. When you are glenda and you connect to another system that has a different authentication server than the one you are in. As glend you usually can log in But as soon as you change to a different user nothing seems to be working right

You can run auth/factotum over and over.

But as soon as you change the user you get the same error. Even drawterm can help you connect directly but you get issues with rcpu.

The easy way around this is to deal with /lib/ndb/local and add a new authentication label to the host you want to connect to.

auth=uriel authdom=macbook
ipnet=macbook ip= ipmask=

ip= sys=uriel dom=uriel.9front ether=525400123456 
ip= sys=cirno dom=thinktank
ip= sys=maat dom=think
ip= sys=ghob

If you look closely the ipnet is and the auth=uriel and audom=macbook

I have a macbook running 9front on qemu image. But I want to connect to a remote system in a different eco system. It has its own authentication server and domain. The ip address is it auth equal to 'maat' and authdom equal to 'think'.

if you run rcpu -u peter -h maat

The error message is gone and you are able to connect without any problems. This should all be simple but for some reason I missed out and couldn't understand it because I spent most of my time as user 'glenda' on multiple systems. Please don't make that mistake and start creating users that do different things.

To post a comment you need to login first.