[9fans] Authentication debugging help?

[9fans] Authentication debugging help?

[David Eckhardt]

I'm trying to set up a machine to be a fossil/venti file
server plus auth server (I'll tackle a CPU server later).

What I have working so far:

1. Followed standard installation (9pcf kernel, fossil)
   (This includes finding, I believe, an installer bug,
   which I will be happy to document once I have this
   thing working).

2. Branded fossil & venti information onto their respective
   partitions, took an archival snapshot..that all seems to
   work ok.

3. Built 9pccpuf kernel, edited /rc/bin/cpurc.  This
   appears to boot and work ok.

BUT when I try to boot a second machine from the "boot floppy"
the installer made for me (9pcdisk kernel?), the client panics.
I apologize for having left my notes (including the exact panic
message) home with the machine, but it dies very early and I
wasn't able to match the complaint to anything obvious in the
sources.

So, some questions:

1. The initial chunk of the "Data Base" section of authsrv(6),
discussing /lib/ndb/auth, is confusing me.  The text and
comments seem to suggest that "hostid=bootes" refers to a
machine named "bootes" (though I don't see "hostid" used
in ndb(6) to designate machines, only "dom" and "sys").
In fact, it explicitly says "client host's ID".

But in the "Network Database" section of the Wiki's
"Configuring a standalone CPU_server" page, it says

  "Uncomment the two lines indicated in /lib/ndb/auth
  to say that the cpu server owner is allowed to become
  any other user (given the appropriate credentials)".

This sure sounds like "bootes" is a USER, not a "client
host's ID".  And at the top of that document it says

  "You can decide what name to give your cpu server owner.
  This is the user that all the cpu servers run as. We'll
  name the user 'bootes'; it is recommended that you also
  choose 'bootes' as it will appear in the instructions
  frequently."

Again, here it seems inexorable that "bootes" is a user.
Which way is up?  More to the point, what belongs in my
/lib/ndb/auth file?

2. Can somebody give me some step-by-step suggestions of
things to verify?  Things like "On your fs/auth server you
should have a foo process, which you should see in ps, which
should be offering /mnt/xxx and /srv/xxx and there should be
a /rc/bin/service.auth/ilYYY file and if you "telnet srvname YYY"
the greeting should be "zzz".

3. Likewise, I would appreciate any detailed suggestions about
how to simulate the terminal-booting-from-server process from
an outside machine, things like "boot the installer CD-ROM on
the client, login in as "none", set auth=srvname, run auth/keyfs,
then auth/factotum, ..."

4. From grubbing around on the server, it's not clear that
the secstore daemon is running.  At least I don't see
something in /rc/bin/service.auth or /rc/bin/cpurc which
would start it...or am I overlooking something obvious?
Can fossil on the server authenticate clients without
its factotum (running as bootes) having access to its
key(s)?

Dave Eckhardt

Re: [9fans] Authentication debugging help?

[Fco.J.Ballesteros]

> comments seem to suggest that "hostid=bootes" refers to a
> machine named "bootes" (though I don't see "hostid" used
> in ndb(6) to designate machines, only "dom" and "sys").
> In fact, it explicitly says "client host's ID".

The hostid names the user that boots the machine (i.e. its owner),
whose auth domain and password you'll keep in nvram.

For example, if that user name is elf (it's bootes in the distribution),
the entry would be:

hostid=elf
	uid!=sys uid!=adm uid=*

That suffices for your auth file.

Probably that would allow your client to authenticate. Also, don't
forget to open your accounts.

Re: [9fans] Authentication debugging help?

[matt]

> it's not clear that the secstore daemon is running.

I had to add

auth/secstored

to cpurc

and it worked

m

Re: [9fans] Authentication debugging help?

[David Presotto]

> 1. The initial chunk of the "Data Base" section of authsrv(6),
> discussing /lib/ndb/auth, is confusing me.  The text and
> comments seem to suggest that "hostid=bootes" refers to a
> machine named "bootes" (though I don't see "hostid" used
> in ndb(6) to designate machines, only "dom" and "sys").
> In fact, it explicitly says "client host's ID".

Host id is the id of the 'owner' or the host, i.e., the
name used when you booted the system.  If it's a cpu server,
you probably got asked:

authid?

That's the host id we're talking about.  Bootes is just an
example of one.

> 2. Can somebody give me some step-by-step suggestions of
> things to verify?  Things like "On your fs/auth server you
> should have a foo process, which you should see in ps, which
> should be offering /mnt/xxx and /srv/xxx and there should be
> a /rc/bin/service.auth/ilYYY file and if you "telnet srvname YYY"
> the greeting should be "zzz".

'netstat -n' should show something listening on tcp ports:

	567 - that's the auth service
	564 - that's the fossil server

'ps' should show a keyfs process running.

'ndb/query authdom <the name of your authentication domain>'
should return a tuple that includes, among other things,
the pair 'auth=<name (or address) of your auth server>'.

'ndb/csquery' followed by the query 'net!$auth!ticket'
should return to you the response:

	/net/tcp/clone <ip address of the auth server>!567

What is serving DHCP for this network?  The newly booted system
will first do a DHCP request to find out it's address, the address
of the dns servers, the address of auth server, and the address
of the file server.  If it fails to get any of these, it will
prompt for them on the console.  Is it getting that far?

Re: [9fans] Authentication debugging help?

[davide+p9]

> Host id is the id of the 'owner' or the host, i.e., the
> name used when you booted the system.

I'm not yet certain I understand *exactly* what that
tuple in /lib/ndb/auth means... is it:

1. "Anybody on any host who can prove to the auth
server on the auth host that he's bootes is allowed
to become anybody (except for adm and sys, if I recall)
on any host which trusts that auth host"

or

2. "Anybody on *any* host who can prove to the kernel
on that host that he's bootes is allowed to become
anybody (!adm, !sys) on that host"

or something else?

> 'netstat -n' should show something listening on tcp ports: [...]
> 'ps' should show a keyfs process running.
> [...]

Excellent, I will check these this evening when I'm home.

> What is serving DHCP for this network?

A LinkSys BEFSR41 NAT box.  The auth/fossil server manually
ipconfig's an address outside the range managed by the LinkSys.
I set bootargs (or is it bootfile?) to "il -d" if I recall,
so the client should be assigned an IP address by the LinkSys.

> The newly booted system will first do a DHCP request to find out
> it's address, the address of the dns servers, the address of auth
> server, and the address of the file server.  If it fails to get
> any of these, it will prompt for them on the console.  Is it
> getting that far?

I used fs= and auth= in PLAN9.ini to point to the IP address
of the auth/fossil server.  So I think it's probably getting
further than that.

Is there a tcpdump/ethereal equivalent I should run on the
server while the client is booting?

Another thing I noticed, which I can't describe exactly
since I left my notes at home, is that "somewhere in
/sys/log" there was a complaint about somebody (maybe
fossil?) not being able to get a role=server dome=? key,
though when I cat'd /mnt/factotum/ctl I see a key (the only
one) which looks to my eyes to match--it doesn't say
role=server but it doesn't say role=anything.

Also, among the various things I've tried, I think I've
seen kernel panics with both "connection refused" and
"connection rejected"--what is the difference between
those?

Dave Eckhardt

Re: [9fans] Authentication debugging help?

[David Presotto]

It's called snoopy.  You can do a

	snoopy -f 'ip(a=<ip address of client>)'

and see of a dump of all the packets from/to that address.

'Connection refused' is what you get if you tried to connect via
tcp and there was no server at the other end.  'Connection rejected'
is the same thing if you tried to connect via il.  I should probably
go through the two protocols and try to consolidate the error messages.

Clearly you've been trying different answers to 'root is from'.  Sounds
like one of:
1) never told your fossil server 'listen tcp!*!564'
2) it couldn't announce on the port for some other reason
like perhaps a 'listen' process was already listening there.
Make sure there are no /rc/bin/service*/tcp564 files lying
around.
3) there isn't a listener for the auth server

The stuff I gave you earlier should detect all or the
above.

If the file server is announced and running right with the file server,

	srv tcp!<ip address of file server>

should work and create a file:

	/srv/tcp!ip address of file server>

I the authentication stuff is working

	mount /srv/tcp!<ip address of file server> /tmp

should work even if you aren't the host owner (hostid
from a previous discussion).  If you are the hostowner,
you can do this even if there is no auth server since
it'll be the same key on both sides and you don't need
a third party with both shared keys.  In fact, that's how
we normally run our cpu servers; they have the same host
owner and password as the file server so that they can
come up even if the one booting is the auth server.

Anyways, tell me how you do.

Re: [9fans] Authentication debugging help?

[David Presotto]

or to paraphrase:

	dude, where's my file server?

Re: [9fans] Authentication debugging help?

[davide+p9]

Got it.  The problem is that I copied these
listen directives from "Setting up Fossil"
on the Wiki:

  listen tcp!*!9fs
  listen il!*!9fs

They *looked* like they were working, since
connecting to the console and typing "listen"
displayed:

  tcp!*!9fs /net/tcp/4
  il!*!9fs /net/il/0

but that was a big lie:  /net/tcp/4/local
showed ::!9 and netstat confirmed that
bootes was listening on the discard port.

I assume this because the Wiki directions
assume you are booting from a kfs so
ndb/cs and friends are already running,
but my fossil was started by /boot?

Dave Eckhardt

Re: [9fans] Authentication debugging help?

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 58 bytes --]

You are correct.  The wiki really should give the numbers.

[-- Attachment #2: Type: message/rfc822, Size: 2463 bytes --]

From: davide+p9@cs.cmu.edu
To: David Presotto <presotto@closedmind.org>, 9fans@cse.psu.edu
Cc: davide+p9@cs.cmu.edu
Subject: Re: [9fans] Authentication debugging help?
Date: Thu, 22 Jan 2004 15:59:05 -0500
Message-ID: <28238.1074805145@piper.nectar.cs.cmu.edu>

Got it.  The problem is that I copied these
listen directives from "Setting up Fossil"
on the Wiki:

  listen tcp!*!9fs
  listen il!*!9fs

They *looked* like they were working, since
connecting to the console and typing "listen"
displayed:

  tcp!*!9fs /net/tcp/4
  il!*!9fs /net/il/0

but that was a big lie:  /net/tcp/4/local
showed ::!9 and netstat confirmed that
bootes was listening on the discard port.

I assume this because the Wiki directions
assume you are booting from a kfs so
ndb/cs and friends are already running,
but my fossil was started by /boot?

Dave Eckhardt

Re: [9fans] Authentication debugging help?

[davide+p9]

>> I assume this because the Wiki directions
>> assume you are booting from a kfs so
>> ndb/cs and friends are already running,
>> but my fossil was started by /boot?

> You are correct.  The wiki really should
> give the numbers.

Done.  Maybe not the best way (it feels to
me like the document could use a general
restructuring), but at least the warning
is there.

Dave Eckhardt