9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Andrew <afrayedknot@thefrayedknot.armory.com>
To: 9fans@cse.psu.edu
Subject: [9fans] setup
Date: Mon,  9 Sep 2002 15:09:44 -0700	[thread overview]
Message-ID: <20020909220944.GA9335@thefrayedknot.armory.com> (raw)

So Ive gotten most things set up correctly on my plan 9 network. I have a
auth/cpu server (ra), a file server (thoth), and even a terminal. The auth
server and terminal both boot off of a floppy and get their root from the
file server, in otherwords they are diskless. Eventually I want to have a
few dedicated cpu servers and about 3-5 terminals spread around my house
for people to use, as well as be able to serve some people outside of the
house through drawterm if possible. The house uses 100 megabit ethernet
and connects out to the world through DSL. My hardware is not top of the
line, most of the systems are older salvaged computers many people would
consider junk. The cpu and file servers right now are just on the order
of pentium 100's. I do plan on scaling things up in the future but for
now this is the hardware I have. That gives you an idea where Im at with
things, I have a few questions I havent found an answer to anywhere else.

I have a small following of people who are interested in plan 9 and
want accounts to do stuff with. I was thinking about using drawterm*
for this. What I was wodering was how many people I could reasonably
expect to serve out of house with drawterms through my dsl link. Is
there some point where network bandwidth gets too high and things are
just too latent? Also, Is there a better way to be doing this sort of
thing? Most of the people interested dont have spare systems to donate
as remote terminals, nor do they have vmware so drawterm seems like the
only way to go.

On the same topic, suppose a person wanted to get their own terminal going
through say a dialup connection, obviously its unreasonable to expect
that to startup diskless, I was thinking i could make use of replica to
install commonly used things to their local disk, what should i include
in the replica (if thats the right approach).

Next Ive been noticing that my auth server periodically loses touch with
the file server and is unable to run any commands or renegotiate the
connection. When at a prompt everything yields "i/o on hungup channel"
the only thing ive found is to reboot the auth server. This seems
strange to me because the two systems are on the same hub connected
through 100megabit ethernet. Is it just from too many collisions, or il
not handling it? Can i use aan to ensure a perminant connection? If so
how do get it to work on the remotely imported root from bootup? Would
adding a cache file system help/resolve the problem?

On cached file systems I was thinking of adding some of my smaller 200-500
mb drives to these systems to act as 9fat/cfs/swap. 9fat needs only to
be big enough to hold the kernel and plan9.ini etc, but im uncertain of
how big to make the cfs and swap partitions. Any thoughts or opinions?

Im also confused about how /rc/bin/service works. I understand that
all the files there are just shell scripts, but is it 'ok' if i have
all my cpu servers looking at the same /rc/bin/service are there any
services in there that are specific to the auth server or are all those
in service.auth? Are there any services in /rc/bin/service that are
best left to just one system to be listening for instead of all the cpu
servers? (if im missing something please tell me).

What ports should be open for the cpu command (and what do they do?). The
manuals say one thing and then the wiki says something slightly different,
I dont want to leave a bunch of ports open when i dont have to. As
far as authenticating cpu connections Im not sure if I have everything
set up right. In order for the command to work I have to set the cpu
variable to tcp!cpuserver!cpu, so in my case tcp!ra!cpu (thats correct
right?). I looked at the debug output from a cpu command on the cpu
server and I noticed that there are a lot of complaints about messages
being the wrong size and that it tries to authenticate as the hostowner
of the cpu server, then fails and tries the username of who executed the
command and finishes the handshaking. Is that what is supposed to happen?

Sorry for the long post, one more thing. Is there a way to 're-login'
on a terminal without rebooting it? I know you can use auth/login to
change the namespace of one window, but is there a way to do it for rio's
namespace? Am i better off having everyone reboot or having it log in
as a guest account and then running a nested rio as a specific user?

Thanks for the help.


Andrew



             reply	other threads:[~2002-09-09 22:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-09 22:09 Andrew [this message]
2002-09-10  4:16 presotto
2002-09-10  6:11 ` Andrew

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=20020909220944.GA9335@thefrayedknot.armory.com \
    --to=afrayedknot@thefrayedknot.armory.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).