Re: [9fans] Issues with 2 networks, fs server, and namespaces

["Devon H. O'Dell" <devon.odell@gmail.com>]

2009/8/21 Christopher Nielsen <cnielsen@pobox.com>:
> You don't need a second IP stack. You can run both interfaces on the
> same IP stack and routing will just work. That's how I did it when I
> had a similar setup.

I do need a second IP stack because the other network is on another
switch on the other interface, and I do not particularly want to run a
private network over the vswitch hooked to the public internet.

--dho

> -Chris
>
> On Fri, Aug 21, 2009 at 14:07, Devon H. O'Dell<devon.odell@gmail.com> wrote:
>> Hello all,
>>
>> I'm trying to set up a group of servers (these are running on VMWare
>> ESXi, and working great -- CPU server running with two APs, though
>> adding more causes it to fault with a divide by zero?). Auth server's
>> got its own 1GB fossil, boots with the 9pcauth kernel. CPU server
>> boots from a small fossil. Both Auth and CPU are on the public
>> internet via ether0 so that they are cpu/drawtermable. They do not
>> boot from the file server because I didn't want to set up a DHCP
>> server that was connected to the Internet (ISP getting mad and
>> whatnot). While I've configured the internal network to be on it's own
>> vswitch (managed through vmware, no real network connectivity), I've
>> been struggling with the prior configuration enough that I don't want
>> to just `give up' on it.
>>
>> The FS, however, sits on a private network. CPU and Auth are connected
>> to this network via ether1. However, I'm having the following issues:
>>
>> #1) Using two networks on two different interfaces is a pain in the
>> ass. I've got:
>> bind '#l1' /net.alt
>> bind '#I1' /net.alt
>>
>> in my /cfg/cpu/namespace. If I simply have them here, ip/ipconfig -N
>> -x ether1 ether /net.alt/ether1 complains in cpurc about no ip being
>> attached to /net.alt. So I have to put that in /cfg/cpu/cpurc also. I
>> don't quite understand why everything's architected to have a single
>> ip stack on a single ethernet; in this case, it really isn't
>> convenient that it doesn't determine the correct interface via routing
>> tables or somesuch. Is there something basic that I'm missing here?
>>
>> #2) Drawterm is taking forever and a day to connect and log in. It's
>> either an auth issue or a DNS issue. Best guesses as to what this
>> could be and how I should go about diagnosing it?
>>
>> #3) Trying to mount the fileserver globally is elusive. I want to
>> mount /n/fs/usr over /usr and /n/fs/mail over /mail. Perfectly happy
>> with that. However:
>>
>>  o Doing that in cpurc doesn't put it in the global namespace
>>  o Doing it in /cfg/cpu/namespace doesn't have an ip yet so I can't
>> run srv /net.alt/tcp!10.0.0.3!9fs in the first place
>>  o Doing it in /rc/bin/service/tcp17010 causes me to get `cpu:
>> negotiating authentication method: [public auth server ip]: cs gave
>> empty translation list'
>>
>> Mounting it from /n/fs after booting works fine (but it makes me auth,
>> which is kind of weird -- I guess I need to set up a secstore? -- I
>> figured that eve would be able to connect without auth, given that
>> everything's tied to the same auth server, no matter which network
>> it's on, and that a user drawterming in would be able to connect by
>> virtue of having authed when connecting in the first place.)
>>
>> I know the `preferred way' is to boot the CPU server from the
>> fileserver. While I could feasibly reconfigure my setup to do this,
>> I'd prefer to figure it out this way first, given the amount of time
>> I've been banging my head against the wall on it :)
>>
>> --dho
>>
>>
>
>
>
> --
> Christopher Nielsen
> "They who can give up essential liberty for temporary
> safety, deserve neither liberty nor safety." --Benjamin Franklin
>
>