[9fans] CPU Server Wiki, auth/keyfs, and password for the machine.

[9fans] CPU Server Wiki, auth/keyfs, and password for the machine.

[g.pavelcak]

In the Wiki on configuring a standalone cpu server, there is a part that says to run auth/keyfs to provide a password for the machine. Assuming a fresh install, this is done while logged in as glenda.

Is this really necessary? Is it different from zeroing the nvram and then entering authid, password, etc.?

Someday I'll actually understand the authentication pieces here: keyfs, factotum, secstore....

Thanks.

Greg

Re: [9fans] CPU Server Wiki, auth/keyfs, and password for the machine.

[Russ Cox]

> In the Wiki on configuring a standalone cpu server, there is a part that
> says to run auth/keyfs to provide a password for the machine. Assuming
> a fresh install, this is done while logged in as glenda.
>
> Is this really necessary? Is it different from zeroing the nvram and
> then entering authid, password, etc.?

Yes, and yes.

Auth/keyfs is the authentication database.
It holds key info for every user in the
authentication domain it serves, including
whatever user the cpu server itself runs as.

Filling out the nvram sets the info that gets
used to initialize the cpu server's factotum.
Like any other factotum, it needs to have a key
that matches the one in authentication database.

Auth/keyfs could plausibly preinitialize the
entry for the host owner using the nvram key,
and that would be fine most of the time, but
not always.  (It is possible to boot in one auth
domain but load an auth/keyfs and be an auth
server for a second domain.  This is why, for
example, users with accounts on the auth
server sources.cs.bell-labs.com can mount
its fossil but not cpu to the machine.)

Russ

Re: [9fans] CPU Server Wiki, auth/keyfs, and password for the machine.

[Gregory Pavelcak]

Thanks Russ for the typically thoughtful and informative reply. You
are perhaps the most valuable resource on any mailing list anywhere.
There ought to be an award or something.

The reason I ask is that I missed that step the first time I tried to
set up the CPU/Auth server, but I've since gone through it all again
carefully more than once, and I stll get "connection rejected" with
my Ken's file server. (Yes I know fossil/venti is the current
standard, but what can I say, I'm, perhaps irrationally, or at least
non-rationally, attached to the old file server.)

The problem is, other than going through the Wiki and 9fans archives,
which I've done, I don't have any notion of how to find out where I
went wrong. I successfully set this up in the past. I did remember to
add IL back to pccpuf, and, as  I said, I followed the Wiki. I'm at a
loss.

Any pointers appreciated.

Greg

On Jul 26, 2008, at 12:15 PM, Russ Cox wrote:

>> In the Wiki on configuring a standalone cpu server, there is a
>> part that
>> says to run auth/keyfs to provide a password for the machine.
>> Assuming
>> a fresh install, this is done while logged in as glenda.
>>
>> Is this really necessary? Is it different from zeroing the nvram and
>> then entering authid, password, etc.?
>
> Yes, and yes.
>
> Auth/keyfs is the authentication database.
> It holds key info for every user in the
> authentication domain it serves, including
> whatever user the cpu server itself runs as.
>
> Filling out the nvram sets the info that gets
> used to initialize the cpu server's factotum.
> Like any other factotum, it needs to have a key
> that matches the one in authentication database.
>
> Auth/keyfs could plausibly preinitialize the
> entry for the host owner using the nvram key,
> and that would be fine most of the time, but
> not always.  (It is possible to boot in one auth
> domain but load an auth/keyfs and be an auth
> server for a second domain.  This is why, for
> example, users with accounts on the auth
> server sources.cs.bell-labs.com can mount
> its fossil but not cpu to the machine.)
>
> Russ
>
>

Re: [9fans] CPU Server Wiki, auth/keyfs,

[erik quanstrom]

> The reason I ask is that I missed that step the first time I tried to
> set up the CPU/Auth server, but I've since gone through it all again
> carefully more than once, and I stll get "connection rejected" with
> my Ken's file server. (Yes I know fossil/venti is the current
> standard, but what can I say, I'm, perhaps irrationally, or at least
> non-rationally, attached to the old file server.)

i am very fond of ken's fs.  it has been very kind to me.
it has withstood my poor programming.

"flag authdebug" is helpful if you have an authentication problem.
also, you don't need to build fossil into the kernel if you don't
use fossil.

- erik

Re: [9fans] CPU Server Wiki, auth/keyfs, and password for the machine.

[Russ Cox]

> The reason I ask is that I missed that step the first time I tried to
> set up the CPU/Auth server, but I've since gone through it all again
> carefully more than once, and I stll get "connection rejected" with
> my Ken's file server. (Yes I know fossil/venti is the current
> standard, but what can I say, I'm, perhaps irrationally, or at least
> non-rationally, attached to the old file server.)

"connection rejected" is a message the file server prints
in the IL stack.  I believe it has nothing to do with
authentication, but I also don't know what the criteria
are for rejection.

You can test connectivity using aux/9pcon:

	cpu% aux/9pcon -n tcp!web.mit.edu!9fs
	aux/9pcon: dial: connection refused
	cpu%

If it does connect (which I doubt), you can try starting
a 9P session:

	cpu% aux/9pcon -n tcp!sources.cs.bell-labs.com!9fs
	Tversion 8192 9P2000
		-> Tversion tag 65535 msize 8192 version '9P2000'
		<- Rversion tag 65535 msize 8192 version '9P2000'
	Tattach 1 -1 rsc ''
		-> Tattach tag 3 fid 1 afid -1 uname rsc aname
		<- Rattach tag 3 qid (0000000000000002 0 d)
	cpu%

9pcon has no prompt; I typed the Tversion and Tattach lines.
Your server will probably reply to the Tattach with an Rerror;
sources is special.

Russ

Re: [9fans] CPU Server Wiki, auth/keyfs, and password for the machine.

[Gregory Pavelcak]

On Jul 26, 2008, at 3:10 PM, Russ Cox wrote:
>>
>
> You can test connectivity using aux/9pcon:
>
> 	cpu% aux/9pcon -n tcp!web.mit.edu!9fs
> 	aux/9pcon: dial: connection refused
> 	cpu%
>
> If it does connect (which I doubt)

Correct.

brain# aux/9pcon -n il!192.168.0.108!9fs
aux/9pcon: dial: connection rejected

Interesting thing here. I'm working on a standalone CPU/Auth server
so that I can mount my file server and populate it. (I had a recent
question about recovering from an old pseudo worm, but after trying
for a while, I became convinced that I had used those disks when I
messed around with DragonFlyBSD, and I re-reamed). So, the kernel I'm
trying is based on pccpuf. In anticipation of taking /root from the
file server, I also made a kernel based on pccpu. I did the same
thing to both: added "il" under "ip" and under "boot" (of course
that's just uncommenting in pccpu), put il.c in /sys/src/9/ip/, and
added Logil and Logilmsg to ip.h. Build went fine. Copy to 9fat.
Menuitems in plan9.ini, and I'm good to go.

The reason I'm boring you with that information, and the part I found
interesting, is this. Just for the heck of it I selected my "CPU,
File Server Root" option, i.e. I booted from 9pccpu instead of
9pccpuf. Of course, the CPU server reboots because there are no files
on the file server yet, but I do seem to get past the il connection
in this case. The file server says:

	il: allocating il!192.168.0.109!43095
	authentication failed: NeedTicket: unknown user
	hangup connection timed out-3 43095/192.168.0.109.17008

Gee. Nice to have some indication that I will have authentication
issues too, once I get il to connect.

Any thoughts (other than "man you really botched this
installation!") :-)

Greg

Re: [9fans] CPU Server Wiki, auth/keyfs,

[erik quanstrom]

> brain# aux/9pcon -n il!192.168.0.108!9fs
> aux/9pcon: dial: connection rejected

does /net/il exist?  you may want to check with snoopy
to make sure packets are making it out, too.
cs and a few other programs have had il-ectomies.

> The reason I'm boring you with that information, and the part I found
> interesting, is this. Just for the heck of it I selected my "CPU,
> File Server Root" option, i.e. I booted from 9pccpu instead of
> 9pccpuf. Of course, the CPU server reboots because there are no files
> on the file server yet, but I do seem to get past the il connection
> in this case. The file server says:
>
> 	il: allocating il!192.168.0.109!43095
> 	authentication failed: NeedTicket: unknown user
> 	hangup connection timed out-3 43095/192.168.0.109.17008

you need to enter "users default" at the fs console for initial connection.
if you have a non-standard hostowner, you will need to add that user
as well.  (fs(8).)

once the user is place "flag authdisable" will disable authentication
if necessary.  you must connect as a known user.

- erik

Re: [9fans] CPU Server Wiki, auth/keyfs,

[Skip Tavakkolian]

> Any thoughts (other than "man you really botched this
> installation!") :-)


to recap, you can mount the fs from a pccpuf - with the root coming
from a local fs, i assume - but can't boot with the root coming from
fs.

is the domain/hostowner/key combo for fs the same as auth/cpu (values
in nvram)?

does hostowner/key in nvram match user/pass held in keyfs for the
hostowner id?

Re: [9fans] CPU Server Wiki, auth/keyfs,

[Gregory Pavelcak]

On Jul 27, 2008, at 10:55 AM, Skip Tavakkolian wrote:

> to recap, you can mount the fs from a pccpuf - with the root coming
> from a local fs, i assume - but can't boot with the root coming from
> fs.
>
Nope, I cannot mount the fs from my CPU server with a local root.
And, perhaps I should change the subject at this point, because while
I had assumed it was an authentication problem, Russ pointed out that
there was no il connection established, so authentication isn't
really relevant (yet).

What I thought was interesting was that it appears that the il
connection is established when I try to boot my CPU server with a
file server root. Though nothing much more happens because the file
server is not yet populated with the distribution.
>

> On Jul 27, 2008, at 10:42 AM, erik quanstrom wrote:

>> does /net/il exist?  you may want to check with snoopy
>> to make sure packets are making it out, too.
>> cs and a few other programs have had il-ectomies.
>>
>>>

Erik,

It looks like /net/il is there. Here's some "stuff".



brain# ls -l /net/il
d-r-xr-xr-x I 0 bootes  bootes 0 Jul 27 14:43 /net/il/0
--rw-rw-rw- I 0 network bootes 0 Jul 27 14:43 /net/il/clone
--r--r--r-- I 0 network bootes 0 Jul 27 14:43 /net/il/stats
brain# ls -l /net/il/0
--rw-rw---- I 0 bootes bootes 0 Jul 27 14:43 /net/il/0/ctl
--rw-rw---- I 0 bootes bootes 0 Jul 27 14:43 /net/il/0/data
--rw-rw---- I 0 bootes bootes 0 Jul 27 14:43 /net/il/0/err
--rw-rw---- I 0 bootes bootes 0 Jul 27 14:43 /net/il/0/listen
--r--r--r-- I 0 bootes bootes 0 Jul 27 14:43 /net/il/0/local
--r--r--r-- I 0 bootes bootes 0 Jul 27 14:43 /net/il/0/remote
--r--r--r-- I 0 bootes bootes 0 Jul 27 14:43 /net/il/0/status
brain# srv il!192.168.0.108!9fs pinky /n/pinky
srv: dial il!192.168.0.108!9fs: connection rejected
brain# cat /net/il/0/status
Listen qin 0 qout 0 del 00050 Br 00100 md 00050 una 00000 rex 00000
rxq 00000 max 00000



And here's snoopy when I run "srv il!192.168.0.108 pinky /n/pinky"

005784 ms
	ether(s=0002b3079b14 d=003048119871 pr=0800 ln=60)
	ip(s=192.168.0.109 d=192.168.0.108 id=6d28 frag=0000 ttl=255 pr=40
ln=38)
	il(s=36357 d=9 t=Sync id=31422 ack=0 spec=0 ck=f720 ln=18)
005786 ms
	ether(s=003048119871 d=0002b3079b14 pr=0800 ln=580)
	ip(s=192.168.0.108 d=192.168.0.109 id=3980 frag=0000 ttl=255 pr=40
ln=566)
	il(s=9 d=36357 t=Close id=0 ack=31422 spec=0 ck=f120 ln=18)
	dump(00be0000204648454a454f434143414341434143414341434143414341434143)

Thanks.

Greg

Re: [9fans] CPU Server Wiki, auth/keyfs,

[erik quanstrom]

> And here's snoopy when I run "srv il!192.168.0.108 pinky /n/pinky"
>
> 005784 ms
> 	ether(s=0002b3079b14 d=003048119871 pr=0800 ln=60)
> 	ip(s=192.168.0.109 d=192.168.0.108 id=6d28 frag=0000 ttl=255 pr=40
> ln=38)
> 	il(s=36357 d=9 t=Sync id=31422 ack=0 spec=0 ck=f720 ln=18)

the destination port seems wrong.  try 17008 as in il!192.168.0.108!17008.

- erik

Re: [9fans] CPU Server Wiki, auth/keyfs,

[Gregory Pavelcak]

After expending all this time and energy, it turns out I was just
getting the srv command wrong. And even after typing the command
about 1000 times, hoping it would work, it never occurred to me that
I should be using the port number. What a dope.

Thanks.

Greg

On Jul 27, 2008, at 12:48 PM, erik quanstrom wrote:

>> And here's snoopy when I run "srv il!192.168.0.108 pinky /n/pinky"
>>
>> 005784 ms
>> 	ether(s=0002b3079b14 d=003048119871 pr=0800 ln=60)
>> 	ip(s=192.168.0.109 d=192.168.0.108 id=6d28 frag=0000 ttl=255 pr=40
>> ln=38)
>> 	il(s=36357 d=9 t=Sync id=31422 ack=0 spec=0 ck=f720 ln=18)
>
> the destination port seems wrong.  try 17008 as in il!192.168.0.108!
> 17008.
>
> - erik
>
>

Re: [9fans] CPU Server Wiki, auth/keyfs,

[erik quanstrom]

> After expending all this time and energy, it turns out I was just
> getting the srv command wrong. And even after typing the command
> about 1000 times, hoping it would work, it never occurred to me that
> I should be using the port number. What a dope.

i didn't see a mistake in what you were typing.  this works
for me

	srv il!buda!9fs buda

however, if i do this

	; 9fs sources
	; bind -a '#I' /net.alt
	; bind -a '#l0' /net.alt
	; mount -a '#s/dns' /net.alt
	; /n/sources/plan9/386/bin/cs -f $ndbfile -x /net.alt
	; echo $ndbfile
	/lib/ndb/local
	; /n/sources/plan9/386/bin/ndb/cs -f $ndbfile -x /net.alt
	; srv /net.alt/il!192.168.0.139!9fs budacon
	srv: dial /net.alt/il!192.168.0.139!9fs: connection rejected

i think the problem is that ndb/cs has forgotten how to il.

add this back into cs, and you'll be good to go:

- erik

----

enum
{
	Nilfast,
	Ntcp,
	Nil,
	Nudp,
	Nicmp,
	Nicmpv6,
	Nrudp,
	Ntelco,
};

/*
 *  net doesn't apply to (r)udp, icmp(v6), or telco (for speed)
 */
Network network[] = {
[Ntcp]		{ "tcp",	iplookup,	iptrans,	0, 0 },
[Nilfast]	{ "il",		iplookup,	iptrans,	0, 1 },
[Nil]		{ "il",		iplookup,	iptrans,	0, 0 },
[Nudp]		{ "udp",	iplookup,	iptrans,	1, 0 },
[Nicmp]		{ "icmp",	iplookup,	iptrans,	1, 0 },
[Nicmpv6]	{ "icmpv6",	iplookup,	iptrans,	1, 0 },
[Nrudp]		{ "rudp",	iplookup,	iptrans,	1, 0 },
[Ntelco]	{ "telco",	telcolookup,	telcotrans,	1, 0 },
		{ 0 },
};