CPU authentication...

CPU authentication...

[Steve]

> Here's a few questions:
> 2. When I do a cpu command - I get the error 
> cpu: can't authenticate: huygens: refused by server

check /sys/log/auth for error messages

> I'm slightly confused here... doesn't the fact that I have booted my
> terminal and connected to my home directory mean that I have been 
> authenticated?

try typing the _wrong_ password, to make sure it is really authenticating you

> I notice also that /dev/hostdomain is empty when I boot the terminal.

it is empty on my terminal also, so that should be fine (I think)

> The cpu server comes up with
> boot: can't read nvram: unknown device in # filename
> boot: bad nvram key:
> 
> It then comes out and asks for the password... I provide the password
> (The same as the server) - it prompts for the authid, and the domain
> I provide it. - And it seems to work.  
> It then prompts:
> boot: can't write key to nvram: fd out of range or not open.

that doesn't sound good. Maybe take a look at
http://www.ecf.toronto.edu/plan9/info/steve/plan9.install-guide

CPU authentication...

[forsyth]

> The cpu server comes up with
> boot: can't read nvram: unknown device in # filename
> boot: bad nvram key:
> 
> It then comes out and asks for the password... I provide the password
> (The same as the server) - it prompts for the authid, and the domain
> I provide it. - And it seems to work.  
> It then prompts:
> boot: can't write key to nvram: fd out of range or not open.

most PCs haven't got any usable NVRAM, so the CPU server
uses a special disc partition instead.  if that doesn't exist, or
(as in this case) the appropriate SCSI or IDE device isn't configured,
you'll get the diagnostics you show above.  in other words,
they are `normal' on a PC.

when it's convenient, you should apply the updates to auth/wrkey and /sys/src/9/boot,
if you haven't done already.

CPU authentication...

[Thomas]

I've gotten three machines running... a cpu, a terminal and a fileserver.

Its obvious that the cpu server and the fileserver are talking to each...
I installed the CDROM over the net to the fileserver.

The terminal boots up and when I enter username and password, it connects
to the fileserver.

This is major progress over a week ago.

Here's a few questions:
1. Is it necessary to set the ipauth variable on the file server?
   Or does it suffice for it to be 0.0.0.0?
2. When I do a cpu command - I get the error 
cpu: can't authenticate: huygens: refused by server

(huygens is the cpu server)
  
   I've fixed the errata with il=ticket service missing from /lib/ndb/local.
   That doesn't seem to fix it.

I'm slightly confused here... doesn't the fact that I have booted my
terminal and connected to my home directory mean that I have been 
authenticated?

I notice also that /dev/hostdomain is empty when I boot the terminal.

I'm also slightly confused about how the domains work.
The default setup on the cpu server sets up /lib/ndb/local as having
sysname=9auth, but dom=auth.$(DOMAINNAME)
Are the supposed to be the same?

I've gotten the terminal to bootp off of the cpu server, but it still insists
on asking me whether I'd like to boot off of [il,9600] etc.

The cpu server comes up with
boot: can't read nvram: unknown device in # filename
boot: bad nvram key:

It then comes out and asks for the password... I provide the password
(The same as the server) - it prompts for the authid, and the domain
I provide it. - And it seems to work.  
It then prompts:
boot: can't write key to nvram: fd out of range or not open.

The file server says that it allocated a channel, at least that is
what I'm interpreting the message on the file server as.

Any comments as to what I'm doing wrong would be appreciated.  Any 
clarifications are helpful.

I've modified cpurc to appropriatedly deal with the name huygens.

What is the meaning of the phrase
"Later, when everything seems solid, you should convert the 
CPU/authentication server to boot from local disk.  It will then be
able to server Plan9 BOOTP request." (Docs, p. 459)

I apologize for the bandwidth usage - but I figure after I've spent 10 hours
or so trying all the different things I can and looking through all the 
manuals - then its worth a question or two

-Tom

---- Where theory and reality meet. 
---- Thomas Riemer, triemer@wesleyan.edu