Setting up a networked 9front machine

First off, we’ll make our life bearable by setting up a temporary cpu service listener. This will let us access the new system with rcpu(1) or drawterm(1), instead of having to suffer some terrible VNC console or similar.

Make sure the machine has network access, then run the following:
```
echo 'key proto=dp9ik dom=9front user='$user' !password=BADBADDIE' >/mnt/factotum/ctl
aux/listen1 -t 'tcp!*!rcpu' /rc/bin/service/tcp17019
```
Complete the standard installation using inst/start, then reboot into a newly installed system.

The following steps assume the cwfs(4) was selected as the file server, and that the basic networking works.
Start with adding your own user to the file server, also add it to some standard groups:
```
; con -C /srv/cwfs.cmd
newuser kvik
newuser sys +kvik
newuser adm +kvik
newuser upas +kvik
```
Before proceeding, restart the machine and log in with the new user, then run:
```
/sys/lib/newuser
```
This will set up your home directory.
Setting up the CPU listener

For CPU listener to get started at boot time it is enough to set the service= parameter in plan9.ini:
```
service=cpu
```
Setting up hands-free booting

While booting the system will prompt for several parameters like the disk partition to mount, user name and password, and possibly some others. This is an issue for CPU servers which usually boot in the dark, with no one present at the console to confirm the defaults. We want to specify and confirm these parameters up front instead.

First, we want to skip the bootargs prompt asking us to select the partition to boot from. This is done by changing the plan9.ini key bootargs= to nobootprompt=; the value stays the same.
```
bootargs=local!/dev/sdF0/fscache
# change to...
nobootprompt=local!/dev/sdF0/fscache
```
Next we’ll store the hostowner authentication credentials. These must be stored in the so-called NVRAM, which is just a small disk partition on PC systems. We can write to it with the auth/wrkey(8) command.

NOTE Make very sure to enter correct information when prompted. It is very common for people to mistype their password, or specify a wrong authentication domain, or even username, which will cause very hard to diagnose problems later on. The same information will be asked for later when creating an auth user and configuring the authentication server.

NOTE 2 If you have followed the step 1. then it is best to explicitly specify the nvram partition that you want to write to. On PC some automatic process is used to find a suitable partition. It is very likely that this process will guess wrong. Use the nvram= environment variable to select the correct partition:
```
; nvram=/dev/sdF0/nvram auth/wrkey
bad nvram des key
bad authentication id
bad authentication domain
authid: kvik
authdom: a-b.xyz
secstore key: <press enter to skip>
password: <type your password>
confirm pasword: <retype your password>
```
Setting up the AUTH server

We are almost done and ready to reboot, but almost nothing set up above will work before an authentication server is running.

First we’ll have to make sure that the authentication server process starts during boot. This is done automatically by the CPU machine’s bootup procedure if it learns that it is supposed to be the authentication server. We tell it so by adding an entry in the system network database which associates the machine, the auth server, with an authentication domain that it will serve.

Add the following entry on a line of its own in the file /lib/ndb/local, replacing the domain with some domain or string of your own:
```
auth=dum authdom=a-b.xyz
```
This associates the machine named dum with the authentication domain a-b.xyz. Remember that this was the same authdom: that we stored in the machine’s nvram with auth/wrkey.

NOTE this entry is independent from everything else in this file. Do not add it to either the ipnet= entry, or the sys= line.

On next reboot the machine dum will figure out it’s supposed to be an authentication server and start the services it needs to act as one.

Now we can add users to the auth server. For this start a temporary keyfs(4), then use auth/changeuser(8) command to add users:
```
; auth/keyfs
; auth/changeuser kvik
Password: <same as what's in nvram>
Confirm password: 
assign new Inferno/POP secret? [y/n]: n
Expiration date (YYYYMMDD or never)[never]: 
Post id: 
User's full name: 
Department #: 
User's email address: kvik@a-b.xyz
Sponsor's email address: 
user kvik installed for Plan 9
```
Final step involves letting our new user “speak for” other users. This is neccessary if the hostowner of the machine running the auth server is someone other than glenda, which is the case here.

Simply add the following entry to the file /lib/ndb/auth:
```
hostid=kvik
       uid=!sys uid=!adm uid=*
```
Reboot
```
fshalt -r
```
After reboot the machine should bring itself up automagically and let you connect to it using drawterm or rcpu.