shithub: docs.9front.org

Info  •  Files  •  Log

cpu-setup: fixes

--- a/cpu-setup.md

+++ b/cpu-setup.md

@@ -75,8 +75,8 @@

 4. Setting up the CPU listener

-   For CPU listener to get started it is enough to set the `service=`

-   boot parameter in `plan9.ini`:

+   For CPU listener to get started at boot time it is enough to set

+   the `service=` parameter in `plan9.ini`:

 	service=cpu

@@ -84,21 +84,22 @@

    In step 3. we've set up the `nobootprompt=` parameter, which makes

    sure the root file system is mounted automatically at boot.  

-   In this step we'll set up hostowner credential, the user name,

-   avoiding the need for manual intervention at the system console.

+   In this step we'll set up hostowner credentials, the user name and

+   password, so as to avoid the need for manual intervention on the

+   system console.

    The auth credentials must be stored in the system NVRAM, which

-   is usually a small disk partition on the PC systems.  We can

-   write to it with the help of the `auth/wrkey(8)` utility.

+   is usually a small disk partition on PC systems.  We can

+   write to it with the `auth/wrkey(8)`.

-   **NOTE** make very sure to enter correct information when prompted.

+   **NOTE** Make very sure to enter correct information when prompted.

    It is very common for people to mistype their password, or specify

-   the wrong authentication domain, or even username, which will cause

+   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 0. then it is best to

+   **NOTE 2** If you have followed the step 0. 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

@@ -111,18 +112,16 @@

 	authid: kvik

 	authdom: a-b.xyz

 	secstore key: <press enter to skip>

-	password: <type the password you wanna use>

+	password: <type your password>

 6. Setting up the AUTH server

-   We are almost done and ready to reboot, but almost nothing we set

-   up above will work before we set up an authentication server

-   which will authenticate us — the remote client — before letting'

-   us connect.

+   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 intended

+   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

@@ -140,15 +139,14 @@

    **NOTE** this entry is independent from everything else in this

    file. Do not add it to either the `ipnet=` entry, or the `sys=`

-   line. 

+   line.

-   On the next reboot the machine `dum` will figure out it's supposed

+   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

-   we'll need to start up a temporary `keyfs(4)`, then use the

-   `auth/changeuser(8)` command to add the users:

+   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

@@ -163,10 +161,10 @@

 	Sponsor's email address: 

 	user kvik installed for Plan 9

-   The last step involves letting our new user "speak for" other users.

-   This is a neccessary step if the hostowner of the machine

+   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 for the setup we performed above.

+   is the case here.

    Simply add the following entry to the file `/lib/ndb/auth`:

@@ -177,5 +175,5 @@

 	fshalt -r

-   After reboot the machine should let you connect to it using

-   `drawterm` or `rcpu`.

+   After reboot the machine should bring itself up automagically and

+   let you connect to it using `drawterm` or `rcpu`.