9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Russ Cox <russcox@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] 9grid.us
Date: Wed, 25 May 2005 00:54:19 -0400	[thread overview]
Message-ID: <ee9e417a0505242154412259a6@mail.gmail.com> (raw)
In-Reply-To: <9fca1fb4e22eca6ddc267ad1ed10bb1f@orthanc.cc.titech.ac.jp>

> > The difference is that standalone doesn't authenticate to
> > its own file server.  The file server trusts the local connection
> > in order to bootstrap.
> 
> The file server means fossil alone?  Or does it include ken fs
> and/or kfs?  Could you give me any pointers to the source where
> this separation occurs?

Both fossil and kfs have provisions for not requiring the
local cpu or terminal kernel to authenticate.  /sys/src/fs
does not, because /sys/src/fs cannot run on the same
machine as one of its clients.

In fossil, the setup is by convention: the config sets up
/srv/fossil using -A to tell it not to require authentication.
In kfs the setup is hard-wired into the code, but the effect
is the same: connections via /srv/boot do not require
authentication.  In both cases, the local kernel is the only
client, and it is assumed to be authenticating its clients
already, so fossil/kfs believes it.

> > You need to add a factotum key for the file server.
> 
> Supposing the following case, what key should I add to which factoum?
> Now a fileserver (fossil) has one (and only one) key:
> 
>         user=sauron dom=tip9ug.jp
> 
> and a diskless cpu server which boots from the
> fileserver has the two keys respectively in their factotums:
> 
>         user=sauron dom=tip9ug.jp
>         user=grid dom=9grid.jp
> 
> Now, one can login to the cpu server using either of the following keys:
>         user=nashi dom=9grid.jp
>         user=nashi dom=tip9ug.jp

So far so good.  If you wanted to disallow using the tip9ug.jp
key to cpu into the cpu server, you could use "user=sauron
dom=tip9ug.jp role=client" as the key in the server factotum.

> However, one can't login with the "user=grid dom=9grid.jp" key.
> Using this key, cpu just finishes without any error message;
>         term% cpu -h cpuserver
>         term%     <-- cpu just exits
> except the "prompt: attach main as grid: unknown user 'grid'"
> on the fossil console.
> 
> The only difference between nashi and grid is that nashi is
> registered to the fossil while grid is not.

Here the cpu authentication is succeeding but then the
file server doesn't allow the mount because the user is unknown.
You have to add the user.  This is unfortunate for 9grid purposes
but it's the way it is.  I suspect you are also going to need 
your cpu server's host id to be able to speak for the incoming users
in order to mount the root file system before there is a /mnt/factotum
for the user, which is also unfortunate.  There are definitely still
issues to be resolved -- the hooks for cross-domain authentication 
are there in factotum but the rest of the system will need some work.

Russ


  reply	other threads:[~2005-05-25  4:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-25  4:39 YAMANASHI Takeshi
2005-05-25  4:54 ` Russ Cox [this message]
2005-05-25  5:20   ` Lucio De Re
     [not found]   ` <1c63862e8858694ce3b83f5d372ad789@proxima.alt.za>
2005-05-25  5:32     ` Russ Cox
2005-05-25  6:11       ` Lucio De Re
2005-05-25  6:09         ` Russ Cox
2005-05-25  6:27           ` Lucio De Re
2005-05-25  6:28       ` Lucio De Re
2005-05-25  9:04         ` C H Forsyth
2005-05-25  9:32           ` Lucio De Re
  -- strict thread matches above, loose matches on Subject: below --
2005-05-25  7:26 YAMANASHI Takeshi
2005-05-25  6:34 YAMANASHI Takeshi
2005-05-25  6:56 ` Lucio De Re
2005-05-25  2:33 YAMANASHI Takeshi
2005-05-25  2:39 ` Russ Cox
2005-05-25  1:52 YAMANASHI Takeshi
2005-05-25  2:02 ` Eric Van Hensbergen
     [not found] <237c0daf7d8dd5561cf95744c7516fd0@orthanc.cc.titech.ac.jp>
2005-05-24 12:56 ` Eric Van Hensbergen
2005-05-22 17:14 Eric Van Hensbergen
2005-05-22 17:21 ` Russ Cox
2005-05-23 14:03   ` Eric Van Hensbergen
2005-05-24  8:13     ` Richard Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ee9e417a0505242154412259a6@mail.gmail.com \
    --to=russcox@gmail.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).