[9fans] have installed plan 9 on many hosts, can't get any of them to "share".

[9fans] have installed plan 9 on many hosts, can't get any of them to "share".

[Lloyd Caldwell]

Synopsis:
	do I give up trying to make a distributed plan 9 home network?
	Is plan 9 worth the struggle?
	The concepts are clearly superior, is it the implementation, is it
the lack of coherent/correct (imho) documentation?

Longer background:

  I noticed that the installation notes now has the statement:

	"If you find yourself reinstalling Plan 9 frequently, something is
wrong. This should not be necessary. In particular, there is no need
to give each Plan 9 system its own file system. "

This is speaking directly to me.

I have been trying to implement plan 9 in a distributed manner for a
long time (since r4 went open source).  I have plan 9 installed on
many computers but none of them allow me to share resource between
boxes.  network booting doesn't work (9pxeload aborts with exception
on all pc's, but I do see the plan 9 pxe banner).  the instructions
for setting up cpu server don't work for me (i.e.: cpu -h cpuhost -u
user yields errors that I can not decode, can't even tell which
"program" is issuing them).  the wiki documents seem to jump from
extremely complicated to extremely trivial.  I have read the
recommended reading list documents multiple times.

I have read a few plan 9 getting started web documents but they all
end abruptly.  The man pages say different things then the 9fans list
people say and the code is written by really smart people who use (to
me) un-informative variable names (please don't flame me for that
statement, you folks are the pro's and I defer to your taste in
naming, I just can't figure out what you're doing from reading the
code).

I'm not a computer scientist but in past jobs have installed/managed
many large unix, windoz, distributed systems, including source only
systems.

Should I abandon attempting to build a plan 9 distributed system?  I
just want to setup an isolated (no internet connection) home
environment.  I have written drivers for my custom devices, ported
the kernel to some arm boards, written some csg code but am tired of
sneaker net file transfer when this beast (plan9) is supposed to be
all network all the time.

Note all of my installs are on bare hardware (i.e.: no vm stuff under
linux, mac, windoz).

Where might I go for a walk thru in setting up a simple plan9
installation, one cpu/auth/fs and one terminal?

sorry for the extent of this message, frustrated and the learning
curve seems to have infinite slope.

regards
Lloyd Caldwell
lmc@xmission.com

Re: [9fans] have installed plan 9 on many hosts, can't get any of them to "share".

[erik quanstrom]

On Thu Dec  9 17:56:39 EST 2010, lmc@xmission.com wrote:
> Synopsis:
> 	do I give up trying to make a distributed plan 9 home network?
> 	Is plan 9 worth the struggle?
> 	The concepts are clearly superior, is it the implementation, is it
> the lack of coherent/correct (imho) documentation?

computers are annoying.

if you have a specific question or a specific failure case,
i'm sure the list will try to address it.

- erik

Re: [9fans] have installed plan 9 on many hosts, can't get any of them to "share".

[John Floren]

On Thu, Dec 9, 2010 at 5:53 PM, Lloyd Caldwell <lmc@xmission.com> wrote:
> Synopsis:
>        do I give up trying to make a distributed plan 9 home network?
>        Is plan 9 worth the struggle?
>        The concepts are clearly superior, is it the implementation, is it
> the lack of coherent/correct (imho) documentation?
>
> Longer background:
>
>  I noticed that the installation notes now has the statement:
>
>        "If you find yourself reinstalling Plan 9 frequently, something is
> wrong. This should not be necessary. In particular, there is no need to give
> each Plan 9 system its own file system. "
>
> This is speaking directly to me.
>
> I have been trying to implement plan 9 in a distributed manner for a long
> time (since r4 went open source).  I have plan 9 installed on many computers
> but none of them allow me to share resource between boxes.  network booting
> doesn't work (9pxeload aborts with exception on all pc's, but I do see the
> plan 9 pxe banner).  the instructions for setting up cpu server don't work
> for me (i.e.: cpu -h cpuhost -u user yields errors that I can not decode,
> can't even tell which "program" is issuing them).  the wiki documents seem
> to jump from extremely complicated to extremely trivial.  I have read the
> recommended reading list documents multiple times.
>
> I have read a few plan 9 getting started web documents but they all end
> abruptly.  The man pages say different things then the 9fans list people say
> and the code is written by really smart people who use (to me)
> un-informative variable names (please don't flame me for that statement, you
> folks are the pro's and I defer to your taste in naming, I just can't figure
> out what you're doing from reading the code).
>
> I'm not a computer scientist but in past jobs have installed/managed many
> large unix, windoz, distributed systems, including source only systems.
>
> Should I abandon attempting to build a plan 9 distributed system?  I just
> want to setup an isolated (no internet connection) home environment.  I have
> written drivers for my custom devices, ported the kernel to some arm boards,
> written some csg code but am tired of sneaker net file transfer when this
> beast (plan9) is supposed to be all network all the time.
>
> Note all of my installs are on bare hardware (i.e.: no vm stuff under linux,
> mac, windoz).
>
> Where might I go for a walk thru in setting up a simple plan9 installation,
> one cpu/auth/fs and one terminal?
>
> sorry for the extent of this message, frustrated and the learning curve
> seems to have infinite slope.
>
> regards
> Lloyd Caldwell
> lmc@xmission.com

If you follow the standalone CPU installation instructions on the wiki
to the letter, you will have a cpu/auth/file server. It's then easy to
export fossil to clients, just set up the configuration to listen on
the appropriate port (the document you want is linked from the
standalone instructions).

Then, once you've got that set up, you install a terminal on another
machine. When it asks for a root, say "tcp" then give it the IP for
your standalone server when it asks. Boom, your terminal now has
remote root. You'll probably want to configure /lib/ndb/local to keep
track of all your systems...

Configuring PXE isn't that tricky but I don't want to run through the
setup process right now, let me know if you need a rundown.

Basically, "> Where might I go for a walk thru in setting up a simple
plan9 installation one cpu/auth/fs and one terminal?" is answered by
"Use the standalone install instructions... and that's basically it."

If you'd give us the errors you're seeing from cpu, we might be able
to help. "Weird errors" isn't very informative!

If it comes down to it, I can exchange some of my config files with
you. I have a standalone cpu server running, with PXE boot working.


John

Re: [9fans] have installed plan 9 on many hosts, can't get any of them to "share".

[Lloyd Caldwell]

John, thanks,

>
> If you follow the standalone CPU installation instructions on the wiki
> to the letter, you will have a cpu/auth/file server. It's then easy to
> export fossil to clients, just set up the configuration to listen on
> the appropriate port (the document you want is linked from the
> standalone instructions).
I followed it to the letter. It has mistakes or inconsistencies (i
think?). for example it says:
	proto=il - recommended (isn't this obsolete?)
	bootf=/386/9pc (It should be bootf=/386/9pxeload)
the bind loop doesn't work with 9pccpuf kernel from install cdrom
(circa dec 2009):
	for (i in m i S t)
		bind -a '#'^$i /dev >/dev/null >[2=1]
fails, complains of no frame buffer (this is from the installation
kernel /386/9pccpuf).  This means no rio on server console so fixing
things requires rebooting into a terminal kernel (I actually know sed
quite well but one gets tired of sed 's/foo/bar/'  filename >j ; mv j
filename :-).

there is no file /rc/bin/service/tcp567 (install image from dec 2009)

The example of a combined cpu/auth server, is not consistent, it
actually is not combined, unless I'm reading it wrong auth is
different then cpu. An excerpt from the 'Configuring a standalone CPU
server' wiki page (cut and pasted at 5:17pm mst today):

A simple example for a combined cpu/auth server, the 192.168.1.100
machine, could be:

ipnet=mynet ip=192.168.1.0 ipmask=255.255.255.0
	auth=bouncer
	cpu=cycles
	dns=lookup
	dnsdom=9fans.net

authdom=9fans.net auth=bouncer

ip=192.168.1.100 sys=bouncer dom=bouncer.9fans.net
ip=192.168.1.101 sys=cycles dom=cycles.9fans.net
ip=192.168.1.102 sys=lookup dom=lookup.9fans.net



>
> Then, once you've got that set up, you install a terminal on another
> machine. When it asks for a root, say "tcp" then give it the IP for
> your standalone server when it asks. Boom, your terminal now has
> remote root. You'll probably want to configure /lib/ndb/local to keep
> track of all your systems...
>
> Configuring PXE isn't that tricky but I don't want to run through the
> setup process right now, let me know if you need a rundown.


If I boot this box from install cdrom and it can obtain ip address
from dhcpd server running on cpu/auth/fs box and see that fs and auth
are setup correctly.  If I attempt to use cpu command from cdrom
booted terminal I get the following error when attempting to connect
to 10.0.1.6 (my combined cpu/auth/fs server).

term% cpu -h 10.0.1.6 -u lmc
cpu: can't authenticate: 10.0.1.6: auth_proxy rpc write: p9sk1@p9-
net: auth_getkey: no /factotum or /boot/factotum: didn't get key !
password? dom=p9-net proto=p9s

the cpu/auth/fs server /lib/ndb/local file is:

#--- start of /lib/ndb/local
ip=127.0.0.1 sys=localhost dom=localhost

ipnet=p9-net ip=10.0.1.0 ipmask=255.255.255.0
	auth=xeon0.p9.net
	cpu=xeon0.p9.net
	fs=xeon0.p9.net

authdom=p9-net auth=xeon0.p9.net

ip=10.0.1.6 sys=xeon0 dom=xeon0.p9.net ether=0007e933c735

ip=10.0.1.7 sys=xeon1 dom=xeon1.p9.net ether=0007e933ca35
	bootf=/386/9pxeload

#--- end of /lib/ndb/local

the plan9.ini file for xeon1 is in /cfg/pxe/0007e933ca35 and contains:

#--- start of xeon1 plan9.ini diskless boot config

nobootprompt=ether0!/386/9pc
mouseport=ps2intellimouse
monitor=xga
vgasize=1024x768x16

#-- end of /cfg/pxe/0007e933ca35

>
> Basically, "> Where might I go for a walk thru in setting up a simple
> plan9 installation one cpu/auth/fs and one terminal?" is answered by
> "Use the standalone install instructions... and that's basically it."
>
> If you'd give us the errors you're seeing from cpu, we might be able
> to help. "Weird errors" isn't very informative!
>
--> Error message from net booting.

Intel(R) Boot Agent FE v4.1.16
Copyright (C) 1997-2004, Intel Corporation

CLIENT MAC ADDR: 00 07 E9 33 CA 35 GUID: 18B58355 0CDA DA11 0080
35CA33E90700
CLIENT IP: 10.0.1.7  MASK: 255.255.255.0  DHCP IP: 10.0.1.6

Plan 9 from Bell Labs by PXE
ELCR: 0E20
pcirouting: 8086/2483 at pin 2 irq 9
FLAGS=10292 TRAP=e ECODE=0 PC=8000a9b3
   AX f000eef3   BX 00000200  CX 00000000    DX 80802798
   SI 80057e3c  DI 00000000   BP 00000000
   CS 0010 DS 0008   ES 0008   FS 0008  GS 0008
   CR0 80000011 CR2 f000eefb CR3 00094000
panic: exception/interrupt 14

Press almost any key to reset.._

<-- End error message from net booting.
I can successfully net boot, linux, freebsd and msdos on this box.  I
get roughly the same errors (different register values) on other
boxes.  I have via epia-m boxes, intel dual xeon boxes, amd64 dual
processor boxes and older pentium 4 boxes. 9pxeload fails similarly
on all of them.  I swapped out the network switch and also tried a
"dumb" hub.

I tried net loading 9pxeloaddebug but the box hangs after getting
it's ip address, i.e. no 'Plan 9 from Bell Labs by PXE' banner.

> If it comes down to it, I can exchange some of my config files with
> you. I have a standalone cpu server running, with PXE boot working

Maybe instead of focusing on net booting.  Are there instructions on
how to connect from one standalone system to another?  cpu doesn't
seem to work.  If I knew I could actually login to a remote box that
would probably help?  Maybe not?  I'm probably thinking about plan 9
all wrong.

anyway thanks.
Regards
Lloyd

>
> John
>

Re: [9fans] have installed plan 9 on many hosts, can't get any of them to "share".

[erik quanstrom]

> Intel(R) Boot Agent FE v4.1.16
> Copyright (C) 1997-2004, Intel Corporation
>
> CLIENT MAC ADDR: 00 07 E9 33 CA 35 GUID: 18B58355 0CDA DA11 0080
> 35CA33E90700
> CLIENT IP: 10.0.1.7  MASK: 255.255.255.0  DHCP IP: 10.0.1.6
>
> Plan 9 from Bell Labs by PXE
> ELCR: 0E20
> pcirouting: 8086/2483 at pin 2 irq 9
> FLAGS=10292 TRAP=e ECODE=0 PC=8000a9b3
>    AX f000eef3   BX 00000200  CX 00000000    DX 80802798
>    SI 80057e3c  DI 00000000   BP 00000000
>    CS 0010 DS 0008   ES 0008   FS 0008  GS 0008
>    CR0 80000011 CR2 f000eefb CR3 00094000
> panic: exception/interrupt 14
>
> Press almost any key to reset.._

try ftp://ftp.quanstro.net/other/9pxeload
if you continue to have this problem, i'll at
least know where to start debugging.

- erik

Re: [9fans] have installed plan 9 on many hosts, can't get any of them to "share".

[John Floren]

On Thu, Dec 9, 2010 at 7:39 PM, Lloyd Caldwell <lmc@xmission.com> wrote:
>
> John, thanks,
>
>>
>> If you follow the standalone CPU installation instructions on the wiki
>> to the letter, you will have a cpu/auth/file server. It's then easy to
>> export fossil to clients, just set up the configuration to listen on
>> the appropriate port (the document you want is linked from the
>> standalone instructions).
>
> I followed it to the letter. It has mistakes or inconsistencies (i think?).
> for example it says:
>        proto=il - recommended (isn't this obsolete?)
>        bootf=/386/9pc (It should be bootf=/386/9pxeload)

il is obsoleted, although a few people do still use it. I have never
used the proto= attribute, don't think you need it. You want to set
bootf=/386/9pxeload for the systems that you want to netboot, for the
others you don't have to set the attribute.

> the bind loop doesn't work with 9pccpuf kernel from install cdrom (circa dec
> 2009):
>        for (i in m i S t)
>                bind -a '#'^$i /dev >/dev/null >[2=1]
> fails, complains of no frame buffer (this is from the installation kernel
> /386/9pccpuf).  This means no rio on server console so fixing things
> requires rebooting into a terminal kernel (I actually know sed quite well
> but one gets tired of sed 's/foo/bar/'  filename >j ; mv j filename :-).
>

I put this in the wiki a bit ago: "In this case we have m (mouse), i
(draw), S (sd - disk), and t (uart - serial); if you get errors about
/dev/realmode, include P in this list". If you're not getting
/dev/realmode complaints, I guess it must be something else.

> there is no file /rc/bin/service/tcp567 (install image from dec 2009)

If it's not there, don't worry about it! I think this might be a
double-check thing, or it might just be an old instruction.

> The example of a combined cpu/auth server, is not consistent, it actually is
> not combined, unless I'm reading it wrong auth is different then cpu. An
> excerpt from the 'Configuring a standalone CPU server' wiki page (cut and
> pasted at 5:17pm mst today):
>
> A simple example for a combined cpu/auth server, the 192.168.1.100 machine,
> could be:
>
> ipnet=mynet ip=192.168.1.0 ipmask=255.255.255.0
>        auth=bouncer
>        cpu=cycles
>        dns=lookup
>        dnsdom=9fans.net
>
> authdom=9fans.net auth=bouncer
>
> ip=192.168.1.100 sys=bouncer dom=bouncer.9fans.net
> ip=192.168.1.101 sys=cycles dom=cycles.9fans.net
> ip=192.168.1.102 sys=lookup dom=lookup.9fans.net
>

What that configuration says is that the *default* cpu server is
cycles. That doesn't necessarily mean bouncer isn't a cpu server too.

>
>>
>> Then, once you've got that set up, you install a terminal on another
>> machine. When it asks for a root, say "tcp" then give it the IP for
>> your standalone server when it asks. Boom, your terminal now has
>> remote root. You'll probably want to configure /lib/ndb/local to keep
>> track of all your systems...
>>
>> Configuring PXE isn't that tricky but I don't want to run through the
>> setup process right now, let me know if you need a rundown.
>
>
> If I boot this box from install cdrom and it can obtain ip address from
> dhcpd server running on cpu/auth/fs box and see that fs and auth are setup
> correctly.  If I attempt to use cpu command from cdrom booted terminal I get
> the following error when attempting to connect to 10.0.1.6 (my combined
> cpu/auth/fs server).
>
> term% cpu -h 10.0.1.6 -u lmc
> cpu: can't authenticate: 10.0.1.6: auth_proxy rpc write: p9sk1@p9-net:
> auth_getkey: no /factotum or /boot/factotum: didn't get key !password?
> dom=p9-net proto=p9s
>
> the cpu/auth/fs server /lib/ndb/local file is:
>
> #--- start of /lib/ndb/local
> ip=127.0.0.1 sys=localhost dom=localhost
>
> ipnet=p9-net ip=10.0.1.0 ipmask=255.255.255.0
>        auth=xeon0.p9.net
>        cpu=xeon0.p9.net
>        fs=xeon0.p9.net
>
> authdom=p9-net auth=xeon0.p9.net
>
> ip=10.0.1.6 sys=xeon0 dom=xeon0.p9.net ether=0007e933c735
>
> ip=10.0.1.7 sys=xeon1 dom=xeon1.p9.net ether=0007e933ca35
>        bootf=/386/9pxeload
>
> #--- end of /lib/ndb/local
>
> the plan9.ini file for xeon1 is in /cfg/pxe/0007e933ca35 and contains:
>
> #--- start of xeon1 plan9.ini diskless boot config
>
> nobootprompt=ether0!/386/9pc
> mouseport=ps2intellimouse
> monitor=xga
> vgasize=1024x768x16
>
> #-- end of /cfg/pxe/0007e933ca35

I'm not sure if this is going to work with the cdrom-booted machine.
It isn't going to have the /lib/ndb/local file, right? So it doesn't
know what the auth server is...

I might be mis-reading the situation.



>
>>
>> Basically, "> Where might I go for a walk thru in setting up a simple
>> plan9 installation one cpu/auth/fs and one terminal?" is answered by
>> "Use the standalone install instructions... and that's basically it."
>>
>> If you'd give us the errors you're seeing from cpu, we might be able
>> to help. "Weird errors" isn't very informative!
>>
> --> Error message from net booting.
>
> Intel(R) Boot Agent FE v4.1.16
> Copyright (C) 1997-2004, Intel Corporation
>
> CLIENT MAC ADDR: 00 07 E9 33 CA 35 GUID: 18B58355 0CDA DA11 0080
> 35CA33E90700
> CLIENT IP: 10.0.1.7  MASK: 255.255.255.0  DHCP IP: 10.0.1.6
>
> Plan 9 from Bell Labs by PXE
> ELCR: 0E20
> pcirouting: 8086/2483 at pin 2 irq 9
> FLAGS=10292 TRAP=e ECODE=0 PC=8000a9b3
>  AX f000eef3   BX 00000200  CX 00000000    DX 80802798
>  SI 80057e3c  DI 00000000   BP 00000000
>  CS 0010 DS 0008   ES 0008   FS 0008  GS 0008
>  CR0 80000011 CR2 f000eefb CR3 00094000
> panic: exception/interrupt 14
>
> Press almost any key to reset.._
>
> <-- End error message from net booting.
> I can successfully net boot, linux, freebsd and msdos on this box.  I get
> roughly the same errors (different register values) on other boxes.  I have
> via epia-m boxes, intel dual xeon boxes, amd64 dual processor boxes and
> older pentium 4 boxes. 9pxeload fails similarly on all of them.  I swapped
> out the network switch and also tried a "dumb" hub.
>
> I tried net loading 9pxeloaddebug but the box hangs after getting it's ip
> address, i.e. no 'Plan 9 from Bell Labs by PXE' banner.
>
>> If it comes down to it, I can exchange some of my config files with
>> you. I have a standalone cpu server running, with PXE boot working
>
> Maybe instead of focusing on net booting.  Are there instructions on how to
> connect from one standalone system to another?  cpu doesn't seem to work.
>  If I knew I could actually login to a remote box that would probably help?
>  Maybe not?  I'm probably thinking about plan 9 all wrong.
>
> anyway thanks.
> Regards
> Lloyd
>
>>
>> John
>>


I'm not exactly sure what's going on with the netbooting problem. The
other best solution is this:
* Install Plan 9 on your terminal machine (to the hard drive)
* When you boot, tell it to get root from TCP and give it the
appropriate IPs (10.0.1.6 in your case)
* Now you have a terminal sharing the root of the server. You can also
cpu if you need, but it's not as big of a deal when you share a root.


John

Re: [9fans] have installed plan 9 on many hosts, can't get any of them to "share".

[Steve Simon]

Its good top remember the learning curve, ir does feel steep,
and then suddenly...

How far have you got installing your plan9 file/cpu/auth server?
I assume you have booted a terminal successfully?

here are some rough steps:
	install a terminal

	edit /lib/ndb/local to set up networking

	partitioned the hard disk, adding an nvram partition.

	modify your plan9.ini - I suggest you add a boot menu to allow you
	to boot as a terminal or as server (different kernels).

	create  /cfg/$sysname/cpurc, I have put mine from my server
	in http://www.quintile.net/doorstep/cpurc, I don't suggest you use this without
	working out what it all does but it should provide a useful template.

	create accounts in fossil for yourself and bootes.

	write the nvram partition using auth/wrkry - hostowner is, by convention,
	"bootes" the authdom is a name for your authentication domain, mine is
	home.quintile.net but your could be anything you like.

	edit /lib/ndb/auth to allow processes running as bootes to become other people.

	set passwords for bootes (same as you used in wrkey) and for yourself
	using auth/changeuser

you will want to set up secstore but that is optional so leave it till later.

there are some nice options to allow the boot sequence (defined in plan9.ini)
to run unattended but these can wait.

you might want to use mirrored drives for reliability, see fs(4).

hope this helps.

-Steve

Re: [9fans] have installed plan 9 on many hosts, can't get any of them to "share".

[Corey]

On Thursday 09 December 2010 3:53:25 Lloyd Caldwell wrote:
> Where might I go for a walk thru in setting up a simple plan9
> installation, one cpu/auth/fs and one terminal?
>

Try this:

http://mirror.9grid.fr/mirror.9grid.fr/plan9-cpu-auth-server-howto.html


Cheers

Re: [9fans] have installed plan 9 on many hosts, can't get any of them to "share".

[John Stalker]

> Synopsis:
> 	do I give up trying to make a distributed plan 9 home network?
> 	Is plan 9 worth the struggle?
> 	The concepts are clearly superior, is it the implementation, is it
> the lack of coherent/correct (imho) documentation?
>
> Longer background:

...skipping...

> Where might I go for a walk thru in setting up a simple plan9
> installation, one cpu/auth/fs and one terminal?
>
> sorry for the extent of this message, frustrated and the learning
> curve seems to have infinite slope.

I tried setting up plan9 networks once or twice a long time ago,
and gave up fairly quickly, partly for the sorts of reasons you
are talking about, but mostly because I don't need a plan9 network.
A standalone system is more than sufficient for what I want.
So none of what I'm going to say below will actually help
you in any way.  But,...

As far as the quality of the available information goes, I think
you are largely correct, but the problem isn't really specific
to plan9.  The situation for BSD is similar, and for most OS's
is worse.  I have doubts about the whole "how to" genre.  For
anything at all complicated you run into at least three problems:
- Actually mistakes.  The code in Kernighan & Richie was copied
  from things that had been compiled and run.  So you knew there
  were no typos.  People who write things for the web still seem
  to think you can reliably give instructions from memory of
  things you last did several years ago.  Without proofreading.
- Version skew.  A well known problem, and the reason I'm using
  MH to send this message.  I like things that don't change, but
  just slowly become obsolete.
- Different situations.  I find I never have the exact same setup
  as the person who wrote whatever I am reading.  And I'm never
  setting out to accomplish the exact same thing.

I'm not really asking people to write better howtos.  I think
the idea is fundamentally broken.  What we really need is some
less narrative and more expository.  I'm not sure what that
would look like, or I would write one.
--
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] have installed plan 9 on many hosts, can't get any of them to "share".

[Steve Simon]

> I'm not really asking people to write better howtos.  I think
> the idea is fundamentally broken.  What we really need is some
> less narrative and more expository.

I agree completely with this, my opinion is we need somthing that explains the
concepts of what has to be done and why, and provides pointers to where to get
the detailed information.

I find once I understand what somthing is trying to do and why, debugging the
details is easy.

For what its worth the biggest problem I ever had setting up a plan9 network
was failing to ensure bootes password was the same in the nvram as in keyfs.

-Steve

Re: [9fans] have installed plan 9 on many hosts, can't get any of them to "share".

[erik quanstrom]

> I agree completely with this, my opinion is we need somthing that explains the
> concepts of what has to be done and why, and provides pointers to where to get
> the detailed information.

unfortunately, it's hard to explain in a vaccuum.  having a working
system makes it much easier to come to grips with the concepts.
but without understanding the system, it's hard to set one up.  thus
the logic of the how-to.

my experience was that it was difficult to understand why plan 9
did many things before i had at least two machines in a plan 9
network.

- erik

Re: [9fans] have installed plan 9 on many hosts, can't get any of them to "share".

[John Floren]

On Fri, Dec 10, 2010 at 10:34 AM, Steve Simon <steve@quintile.net> wrote:
>> I'm not really asking people to write better howtos.  I think
>> the idea is fundamentally broken.  What we really need is some
>> less narrative and more expository.
>
> I agree completely with this, my opinion is we need somthing that explains the
> concepts of what has to be done and why, and provides pointers to where to get
> the detailed information.
>
> I find once I understand what somthing is trying to do and why, debugging the
> details is easy.
>
> For what its worth the biggest problem I ever had setting up a plan9 network
> was failing to ensure bootes password was the same in the nvram as in keyfs.
>
> -Steve
>

My problem was always forgetting to uncomment the keyfs line in cpurc.
I'd be able to log in as bootes but nothing else.

I've done it often enough that I might be able to write a decent
document about setting up a standalone server and some terminals with
explanations of what needs to be done, followed by actual commands to
do it... I think the existing standalone CPU howto document actually
does a pretty good job with that, it's just a little hasty/haphazard
sometimes.

John

Re: [9fans] have installed plan 9 on many hosts, can't get any of them to "share".

[ron minnich]

On Fri, Dec 10, 2010 at 7:42 AM, John Floren <slawmaster@gmail.com> wrote:

> My problem was always forgetting to uncomment the keyfs line in cpurc.
> I'd be able to log in as bootes but nothing else.

Maybe the single most important document would be a set of key-value pairs:
"I have this problem"
"Then you need to this"

ron