9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] setup
@ 2002-09-09 22:09 Andrew
  0 siblings, 0 replies; 3+ messages in thread
From: Andrew @ 2002-09-09 22:09 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [9fans] setup
  2002-09-10  4:16 presotto
@ 2002-09-10  6:11 ` Andrew
  0 siblings, 0 replies; 3+ messages in thread
From: Andrew @ 2002-09-10  6:11 UTC (permalink / raw)
  To: 9fans

> The file server won't run aan.  However, you shouldn't be getting
> hung up.   I take it the terminal doesn't have these problems?  Similar
> hardware or not?  If not, I'ld switch which machine is which and see if
> it moves with the machine or stays with the auth server.

The terminal has the same problem and is connected in a different room.

all three systems use identical i82557 mini-nics.

>
> Cron is probably running periodicly on the auth server.  Is there any
> correlation between auth doing something and the connection going
> south?  Is there anything going on when you get hung up?

cron is actually not running on the system at the moment, I turned it
off because mail wasnt set up at the time and I havent gotten around to
turning it back on

>
> Last but not least, are you on a switch?  Do the switch and cpu agree
> about the line being full duplex or half duplex?  Our track record in
> that department is fuzzy.

the house is on a switch, my room has a hub. The file server and
cpu/auth server are connected through my hub (thus avoiding the
switch). The terminal is in a different room and therefore, does use
the switch. However according to the resident networking guru, the hub
should be transparent so long as ieee standards for ethernet and arp
are maintained regardless of half or full duplex..
>
> If a cache file system helps, it will be because you're side stepping
> the real problem and it'll come back and bit you in the backside.
>
i figured a cache would only avoid the problem for a while, however i
was thinking that maybe if all file access doesnt go away the system
may be able to reconnect...

The last time i made this happen i was connected through 2 ssh links,
telnet, ftp and a drawterm. Im pretty baffled by this one. Thanks for
your help anyways.


> We normally run as few services on the auth server as possible.  However,
> since your auth server and cpu server are the same machine...  Once you
> have your n cpu servers, you can scale back the auth server to do just
> a few things.  We normally run them standalone so that they can't easily
> be hacked because we left something unprotected on the mail file server.
> /rc/ibin/service.auth has the things that need to run as the hostowner.
> It contains things that cpu's run (imap4d, pop3, and ssh servers).  This
> should eventually become the null set because of factotum.  It also includes
> the authentication server (il566 and tcp567).  This needs to run as
> hostowner because it needs to access the key database.

so back to my question, I would assume i need a seperate directory
(perhaps mapped to the same place) for each type of system?
>
>
> The cpu command now uses only tcp port 17010/ncpu.  17013 is only for an
> older version of cpu.  17006 for an older one still.  They're both obsolete.
> If you're running cron, you probably want to leave the rexexec port open also,
> tcp port 17009/rexexec.  Finally, both systemdialing the cpu will have to
> authenticate to your auth server so it needs to get to tcp port 567 on the auth server.

thats a big help, thanks

>
> You should be able to just have the variable
>
> 	cpu=ra
>
> Or you could just use '-h ra' whenever you run cpu.
> By adding the !cpu you're trying to connect to an
> old version cpu server.  I'm surprised anything answers
> at all.  Check that your /lib/ndb/common matches what's
> on sources.cs.bell-labs.com.  It could be that you have
> some odd mix of old and new style cpu clients and servers.

The original standalone system was a release 4 only machine. It installed
from the internet, the file server was populated with the contents
of the iso that came with the installation, once the file server was
filled I disconnected the drive and rebooted the standalone system as
the auth server.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [9fans] setup
@ 2002-09-10  4:16 presotto
  2002-09-10  6:11 ` Andrew
  0 siblings, 1 reply; 3+ messages in thread
From: presotto @ 2002-09-10  4:16 UTC (permalink / raw)
  To: afrayedknot, 9fans

>
> 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?

The file server won't run aan.  However, you shouldn't be getting
hung up.   I take it the terminal doesn't have these problems?  Similar
hardware or not?  If not, I'ld switch which machine is which and see if
it moves with the machine or stays with the auth server.

Cron is probably running periodicly on the auth server.  Is there any
correlation between auth doing something and the connection going
south?  Is there anything going on when you get hung up?

Last but not least, are you on a switch?  Do the switch and cpu agree
about the line being full duplex or half duplex?  Our track record in
that department is fuzzy.

If a cache file system helps, it will be because you're side stepping
the real problem and it'll come back and bit you in the backside.

>
> 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).

We normally run as few services on the auth server as possible.  However,
since your auth server and cpu server are the same machine...  Once you
have your n cpu servers, you can scale back the auth server to do just
a few things.  We normally run them standalone so that they can't easily
be hacked because we left something unprotected on the mail file server.
/rc/ibin/service.auth has the things that need to run as the hostowner.
It contains things that cpu's run (imap4d, pop3, and ssh servers).  This
should eventually become the null set because of factotum.  It also includes
the authentication server (il566 and tcp567).  This needs to run as
hostowner because it needs to access the key database.

>
> 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?

The cpu command now uses only tcp port 17010/ncpu.  17013 is only for an
older version of cpu.  17006 for an older one still.  They're both obsolete.
If you're running cron, you probably want to leave the rexexec port open also,
tcp port 17009/rexexec.  Finally, both systemdialing the cpu will have to
authenticate to your auth server so it needs to get to tcp port 567 on the auth server.

You should be able to just have the variable

	cpu=ra

Or you could just use '-h ra' whenever you run cpu.
By adding the !cpu you're trying to connect to an
old version cpu server.  I'm surprised anything answers
at all.  Check that your /lib/ndb/common matches what's
on sources.cs.bell-labs.com.  It could be that you have
some odd mix of old and new style cpu clients and servers.

I don't understand the short messages unless they're just aborted attempts.
Could you send us some examples of the debugging output?
>
> 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?

no, just reboot.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-09-10  6:11 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-09-09 22:09 [9fans] setup Andrew
2002-09-10  4:16 presotto
2002-09-10  6:11 ` Andrew

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).