A traditional Plan 9 network is distributed and is typically composed of 3 parts: Terminals, CPU servers, and Filesystem servers. A 9front network adds an Auth server, making the total 4 hosts. Luckily, we can configure a single machine to function as the CPU, FS, and Auth server. The Terminal here is another 9front machine or the drawterm program.
There is no easy way to make a 1:1 comparison to a UNIX system but I will try. The FS server is similar to an NFS server. The Auth server is similar ot LDAP. The CPU server is similar to using SSH to connect to a remote host. The Term is your local machine. Behind the scenes, these analogies break down. But they are close enough for a 10,000 foot view.
First, we need to add a user to the file server. The
newuser command is similar to
pw. Then, we add the user to some groups, particarly the system, admin, and mail groups. Whether or not the mail group is necessary, I don't know. It's a standard group so it can't hurt.
% con -C /src/cwfs.cmd newuser username newuser sys +username newuser adm +username newuser upas +username
Set up user homedir
boot with the
user=username bootarg, then run the following command. This is a similar concept to
cp -r /etc/skel /home/username on a UNIX system. Now reboot again.
Setting up headless booting
Typically, a 9 install will ask the user which disk they want to boot from. We can configure it to automatically boot with specific options. First, we mount the 9fat partition. Note that this step differs on systems that are not i386 or amd64.
% 9fs 9fat
Then, we edit the config file with
sam. This is similar to editing
/boot/grub2/grub.cfg on a Linux system or editing
/boot/loader.conf on FreeBSD.
/n/9fat/plan9.ini look like this:
bootfile=9pc64 nobootprompt=local!/dev/sdC0/fscache mouseport=ps2 monitor=vesa vgasize=1024x768x14 user=username tiltscreen=none service=cpu # comment out if it breaks
Storing hostowner info in the NVRAM
The information we store in NVRAM will be automatically loaded at boot time. Make sure you type everything correctly. If your CMOS battery dies, you will have to repeat this step.
% nvram=/dev/sdC0/nvram auth/wrkey bad nvram des key bad authentication id bad authentication domain authid: username authdom: 9front secstore key: <press the return key if you do not want to type this at boot time> password: <make it 8 chars>
The auth server is very simple to set up. Since we have already added a user with a password to this system, we simply instruct 9 to start the start the process at boot time. Append this to
Adding a user to the Auth server
We will now add our user to the Auth server.
% auth/keyfs % auth/changeuser username Password: <what you put earlier> Confirm password: Assign new Inferno/POP secret? [y/n]: n Expiration date (YYYYMMDD or never) [never]: never Post id: User's full name: Department #: User's email address: Sponsor's email address: user username installed for Plan 9
The next step is to add something similar to
sudo permissions. This analogy is completely broken. Append this to /lib/ndb/auth
hostid=username uid=!sys uid=!adm uid=*
Reboot and pray
If something fails, you will need to use ed or sed to fix it. Smile soldier, there are darker days ahead.
Connect with drawterm
To connect to our CPU server, we can use the
drawterm programs. Note that the 9front and Plan 9 From Bell Labs versions of these programs differ substantially because 9front added the concept of auth servers. You can download the source for drawterm here
To connect to a remote system, we specify the username, the CPU server, and the auth server. Since these are on the same box, we will repeat a few arguments.
$ ./drawterm -u username -h 9cpuserv -a 9cpuserv