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
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.
- 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
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=184.108.40.206 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=220.127.116.11 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 18.104.22.168.
/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.
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)
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/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 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
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
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
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=22.214.171.124 sys=maat dom=think auth=maat authdom=think ip=126.96.36.199 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 188.8.131.52 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.