[9fans] Newbie looking for pointers

[9fans] Newbie looking for pointers

[Martín Ferrari]

Hi,

I guess that this must be a FAQ; but I've already spent days googling,
reading docs, man pages, etc. and I'm still lost.

Short background: I'm an experienced (11y) Linux sysadmin, but this is
the first time I try to delve into Plan9. I want to play with it and
to explore it's possibilities in full, so I tried to create a minimal
reproduction of the decentratized scheme shown in the original P9
paper. I've installed successfully some terminals, one with
fossil+venti (which I expect to use as a file server) and a couple of
CPU servers (one following the step-by-step guide, another with a
make_cpuauth script that I found later). All of this in separate QEMU
instances connected by the VDE virtual networking to the host OS that
works as a router to the internet.

I think that networking more or less works (after a LOT of sweat), but
my main problem is that I don't know how to continue. The
documentation doesn't seem to explain how it's supposed that all this
fits together, and I couldn't find any docs on how to use fossil+venti
as a fileserver (the only page I found was for the old system).

I don't understand how the fileserver and the cpu server(s) share
authentication data, how do I setup remote booting for terminals
and/or the fileserver...


All in all, I think that I'm completely blinded to the big picture.
Anyone could give me some tips or pointers?

Thanks you a lot.

-- 
Martín Ferrari

Re: [9fans] Newbie looking for pointers

[Steve Simon]

The system hangs together through an auth system which is distantly related to kerberos.

the file servers and auth servers share a host ID and password, by convention the name
is "bootes". the username and password is stored in a tiny partition on the disk (nvram partition).
this allows them to communicate securely. the classic beginers mistake (I made) was the user
"bootes" must exist on the system and the password bootes has in the auth server
must be the same one as is stored in the nvram.

many auth problems become obvious if you run

	auth/debug

setting up auth is really more about getting your network database (man ndb) correctly
rather than keyfs and secstore which are pretty simple.

fossil will perform two functions, it will serve files to the kernel that boots it
(this is implied in the way fossil is started by the kernel, rather than a feature of fossil)
and, if told to in its config (in the config block at the start of the fossil partition)
it will serve 9p network requests from remote hosts.

-Steve

Re: [9fans] Newbie looking for pointers

[Martín Ferrari]

On Wed, Oct 15, 2008 at 07:22, Steve Simon <steve@quintile.net> wrote:
> The system hangs together through an auth system which is distantly related to kerberos.
>
> the file servers and auth servers share a host ID and password, by convention the name

aha, I didn't understand what "bootes" was for. In any case, when I
first booted the cpu/auth server, I was asked for authid (is this the
same as the hostid you mention?), authdom (I don't get to what this
domain applies, incoming requests to the auth server?) secstore key
(dunno) and password.

> is "bootes". the username and password is stored in a tiny partition on the disk (nvram partition).
> this allows them to communicate securely. the classic beginers mistake (I made) was the user
> "bootes" must exist on the system and the password bootes has in the auth server
> must be the same one as is stored in the nvram.
>
> many auth problems become obvious if you run
>
>        auth/debug

good tip, although I still don't know how to use the auth :)

until now I just have a terminal with venti. $service says "terminal",
it asks me for an user on boot (and has a local glenda user)... From
the docs, isn't it supposed to be unusable from the console? Or this
is just a relic and now any system can be a file server?

> fossil will perform two functions, it will serve files to the kernel that boots it
> (this is implied in the way fossil is started by the kernel, rather than a feature of fossil)
> and, if told to in its config (in the config block at the start of the fossil partition)
> it will serve 9p network requests from remote hosts.

I guess this is accomplished with "fossil/conf –w /dev/sdC0/fossil", right?

Thanks again.

-- 
Martín Ferrari

Re: [9fans] Newbie looking for pointers

[Charles Forsyth]

>>From the docs, isn't it supposed to be unusable from the console? Or this
>is just a relic and now any system can be a file server?

that's a different, older implementation of file service, using its own kernel; it's described by fs(4).
it is still separately available and maintained, but the .iso plan 9 distribution installs
fossil and venti.  (i think venti is optional but i might be wrong.)

venti and fossil run under the normal Plan 9 cpu/terminal kernel. on a cpu server, the kernel
is multi-user (often runs processes owned by different users). on a terminal, the kernel
normally has processes and devices owned by the user name you type when you start it.
essentially the difference is one of configuration; they are built from the same source.
you can run fossil and venti under either of those.  to get the effect of the old arrangement,
you can run the file system programs on a cpu server of their own, with little else running,
and have all the other terminals and cpu servers mount the file system from that machine.
that's what i do at home and at work.  you can also run everything on one machine that's a terminal.
my notebook is set up that way, although i'll boot with root from the net when i'm at home or at work.

more possibilities, probably not useful to you: there is kfs(4), an older program that runs under
the cpu/terminal kernels serving a file system implementation similar to that of the original
specialised file server kernel, but different in a few details, with an slightly different disk format;
and now also cwfs(4) which is essentially the full original
file server as a program running under the cpu/terminal kernels, with the same disk format.

fossil, kfs and cwfs all optionally allow interaction with their `consoles' through a file in /srv.

Re: [9fans] Newbie looking for pointers

[Steve Simon]

> aha, I didn't understand what "bootes" was for. In any case, when I
> first booted the cpu/auth server, I was asked for authid (is this the
> same as the hostid you mention?), authdom (I don't get to what this
> domain applies, incoming requests to the auth server?) secstore key
> (dunno) and password.

sorry, my bad

authid
	This is  the username used for the owner of the auth server, by convention "bootes"

authdom is the name of the adminstrative domain that authentication will be performed in
		usually this is just your DNS domain name, but you could have

			usa-east.domain.dom
			china-north.domain.dom
			sales.domain.dom
			finance.domain.dom

		so each group gets its own auth server which are and each have 
		their own adminstrator. there are also good RTT reasons for having
		geographicially local auth servers.


> until now I just have a terminal with venti. $service says "terminal",
> it asks me for an user on boot (and has a local glenda user)... From
> the docs, isn't it supposed to be unusable from the console? Or this
> is just a relic and now any system can be a file server?

venti is an archival server, you must be using fossil and venti
you could just use fossil on its own but never venti alonw </pedant>

The fact that it is prompting for a user means you are running a terminal
kernel rather than a cpu server kernel. The kernels are the same, they just
boot differently and the cpu kernel has different drivers (e.g. no vga).

just to be absolutely clear, a terminal and cpu server are almost the same thing,
though different files boot. an auth server and a cpu server are cpu serevrs
with different progs running on them. you can even have a terminal which runs
as a cpu server, auth server, and file server (I have one in front of me now).

you can log in as glenda and you can use a character interface (which is
what I think you mean by console), but usually rio (the window manager)
is started in your login script and you work from there. Rio does the interrupt
processing so no rio means no way to stop long running commands.

> I guess this is accomplished with "fossil/conf –w /dev/sdC0/fossil", right?

yep, this writes the config, without the -w it reads it.

Sounds like you understand quite well really, I think you
are further up the learning curve than you think.

-Steve

Re: [9fans] Newbie looking for pointers

[Pietro Gagliardi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Oct 15, 2008, at 8:10 AM, Charles Forsyth wrote:

> (i think venti is optional but i might be wrong.)

Yes, it's optional.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkj2VAwACgkQuv7AVNQDs+xZgACdEsgJT4PaatwcH7wlL6Qm/H62
KyEAnibZ/dBGPvHpGiqusX1HdURPTmUv
=KSZf
-----END PGP SIGNATURE-----

Re: [9fans] Newbie looking for pointers

[Martín Ferrari]

On Wed, Oct 15, 2008 at 11:55, Steve Simon <steve@quintile.net> wrote:

> Sounds like you understand quite well really, I think you
> are further up the learning curve than you think.

Well, it seems that I wasn't so far away, now I'm happily running a
cpu/auth/file server and many disk-less terminals (even tunneling a
VDE connection thru the internet!) without a glitch. And now I have a
brand new toy to discover :)

Thanks a lot for the help, I was completely blocked.

Tincho.

-- 
Martín Ferrari

Re: [9fans] Newbie looking for pointers

[ron minnich]

On Wed, Oct 15, 2008 at 1:54 PM, Martín Ferrari
<martin.ferrari@gmail.com> wrote:
> On Wed, Oct 15, 2008 at 11:55, Steve Simon <steve@quintile.net> wrote:
>
>> Sounds like you understand quite well really, I think you
>> are further up the learning curve than you think.
>
> Well, it seems that I wasn't so far away, now I'm happily running a
> cpu/auth/file server and many disk-less terminals (even tunneling a
> VDE connection thru the internet!) without a glitch. And now I have a
> brand new toy to discover :)
>

You did well. Plan 9 has a learning curve, just remember that for many
things, it is worth it.

ron