(no subject)

[presotto]

To: 9fans@cse.psu.edumail, -s, file system less cpu servers
	, 9fans@cse.psu.edu
Date: Thu, 29 Jun 2000 07:41:17 -0400
From: presotto

To: 9fans@cse.psu.edumail, -s, file system less cpu servers, 9fans@cse.psu.edu
Subject: file system less cpu servers
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="upas-iecfsateqifxydykyxtviylwbo"

This is a multi-part message in MIME format.
--upas-iecfsateqifxydykyxtviylwbo
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

> > Now, I have two file servers and the others are all diskless, all the resources
> > comes from file servers!
> >
> I never quite understood how to make a CPU server diskless, there's
> something there that beats me.  How did you do it?
>
> ++L
>

Our PC's can't be truly diskless, just file system-less.  You
need a disk (hard or floppy) to contain
- the plan9.ini configuration file
- the boot program, 9load(8)
- a floppy file (#f/plan9.nvr) or a hard disk partition
  (/dev/sdC0/nvram, for example) to hold the user id and
   password to connect to the file server as.

Once the boot loader is running, boot the kernel over the
net:  ether0!/386/9pccpu of ether0!xyzzy!/386/9pccpu if you
want to boot from server xyzzy.

At the 'root is from' prompt, choose 'il' and you should
be up and running.  The first time around, you'll be prompted
for user id and password that you want the cpu server to
connect to the file server as.  If you want to connect to
the cpu server as something other than that id, you'll have
to create a speaks for relation in the /lib/ndb/auth file
on the authentication server:

hostid=cpuuserid uid=*

where cpuuserid is the id you choose.  the * means that this
userid can speak for anyone.  You can use a list of specific userid's
if you want to restrict it.

The speaks for isn't all powerful.  You still have to authenticate
your self with a 3 way handshake twixt the cpu server, file
server, and your terminal in order for the cpu server to
speak for you.  This just adds a little more security so
that you don't accidentally connect to an unrusted server.

The big hack is that if there is no auth server, you can just make the
file server and cpu server userid's and passwords the same.
This lets the cpu server connect to the file server before the
auth server is up.  It's the chicken and egg problem that lets
the auth server also be filesystem less.

We run most of our cpu servers off of remote file servers.
The exceptions are our auth server which doubles as a bootp,
dhcp,tftp server to boot all the other systems.  It sits on
a UPS and is really helpfull when power drops.

The other exceptions are our two dns servers which don't
do anything else.

--upas-iecfsateqifxydykyxtviylwbo
Content-Disposition: attachment; filename=quux1
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

> > Now, I have two file servers and the others are all diskless, all the resources
> > comes from file servers!
> >
> I never quite understood how to make a CPU server diskless, there's
> something there that beats me.  How did you do it?
>
> ++L
>

Our PC's can't be truly diskless, just file system-less.  You
need a disk (hard or floppy) to contain
- the plan9.ini configuration file
- the boot program, 9load(8)
- a floppy file (#f/plan9.nvr) or a hard disk partition
  (/dev/sdC0/nvram, for example) to hold the user id and
   password to connect to the file server as.

Once the boot loader is running, boot the kernel over the
net:  ether0!/386/9pccpu of ether0!xyzzy!/386/9pccpu if you
want to boot from server xyzzy.

At the 'root is from' prompt, choose 'il' and you should
be up and running.  The first time around, you'll be prompted
for user id and password that you want the cpu server to
connect to the file server as.  If you want to connect to
the cpu server as something other than that id, you'll have
to create a speaks for relation in the /lib/ndb/auth file
on the authentication server:

hostid=cpuuserid uid=*

where cpuuserid is the id you choose.  the * means that this
userid can speak for anyone.  You can use a list of specific userid's
if you want to restrict it.

The speaks for isn't all powerful.  You still have to authenticate
your self with a 3 way handshake twixt the cpu server, file
server, and your terminal in order for the cpu server to
speak for you.  This just adds a little more security so
that you don't accidentally connect to an unrusted server.

The big hack is that if there is no auth server, you can just make the
file server and cpu server userid's and passwords the same.
This lets the cpu server connect to the file server before the
auth server is up.  It's the chicken and egg problem that lets
the auth server also be filesystem less.

We run most of our cpu servers off of remote file servers.
The exceptions are our auth server which doubles as a bootp,
dhcp,tftp server to boot all the other systems.  It sits on
a UPS and is really helpfull when power drops.

The other exceptions are our two dns servers which don't
do anything else.
--upas-iecfsateqifxydykyxtviylwbo--