CPU-Authentication
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
ed
a
Hello world I hope this works
blah blah
.
w foo.txt
123123
q
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
example:
ed foo.txt
1
hello world I hope this works
2 blah blah
-1
hello world I hope this works
c
hi world I hope this
.
w
31
q
cpu% cat foo.txt
hi world I hope this
blah blah
cpu%
. 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
- setup network database
- edit plan9.ini to boot as a server
- setup nvram
- write to nvram
- add user to auth
- add user to file system
network
edit /lib/ndb/local
Here is my example.
ip=127.0.0.1 sys=localhost dom=localhost
# example: adjust to fit your network
auth=cirno authdom=yoda # i feel like this should stay
ipnet=yoda ip=172.27.0.0 ipmask=255.255.255.0
ipgw=172.27.0.254
dns=172.27.0.254
auth=cirno
authdom=yoda
dnsdom=yoda
cpu=cirno
smtp=smtp.gmail.com
fs=cirno
ip=172.27.0.67 sys=cirno dom=cirno.thinktank ether=0800270312de
ip=35.86.109.161 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 172.27.0.67 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 thinktankworkspaces.com
Here is another example using qemu on AWS ec2.
auth=ghob authdom=thinktankworkspaces
ipnet=thinktankworkspaces ip=10.0.2.0 ipmask=255.255.255.0
ipgw=10.0.2.2
dns=10.0.2.15
auth=ghob
authdom=thinktankworkspaces
dnsdom=thinktankworkspaces
cpu=10.0.2.15
smtp=ghob
fs=ghob
ip=10.0.2.15 sys=ghob dom=thinktankworkspaces ether=525400123456
ip=35.86.109.161 sys=www dom=www.thinktankworkspaces.com
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 35.86.109.161.
/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)'
plan9.ini
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
9bootfat
9pc
efi
pbs.bak
plan9.config
plan9.cpu
plan9.ini
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.
bootfile=9pc
bootargs=local!/dev/sdC0/fscache -a tcp!*!564
nvram=/dev/sdC0/nvram
mouseport=ps2
monitor=vesa
vgasize=1024x768x16
tiltscreen=none
service=cpu
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
bootfile=9pc
bootargs=local!/dev/sdC0/fscache -a tcp!*!564
mouseport=ask
monitor=ask
vgasize=ask
console=0
nvram=/dev/sdC0/nvram
service=cpu
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
nvram
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/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.
Drawterm
you can find it at https://drawterm.9front.org
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://git.9front.org/plan9front/drawterm 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/drawterm.app/”.
I usually run it command line as follows:
plan9front/drawterm-908xxxxxx/gui-cocoa/drawterm.app/drawterm -a 172.27.0.67 -h 172.27.0.67 -u glenda
rcpu errors
If you are connecting from another plan9 system you can type the following:
rcpu -u glenda -h 172.27.0.67
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
auth/factotum
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=10.0.2.0 ipmask=255.255.255.0
ipgw=10.0.2.2
dns=10.0.2.3
auth=uriel
dnsdom=macbook
authdom=macbook
cpu=uriel
smtp=uriel
fs=uriel
ip=10.0.2.15 sys=uriel dom=uriel.9front ether=525400123456
ip=172.27.0.67 sys=cirno dom=thinktank
ip=45.79.94.76 sys=maat dom=think
auth=maat
authdom=think
ip=35.86.109.161 sys=ghob
If you look closely the ipnet is 10.0.2.0 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 45.79.94.76 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.