2009/8/21 Christopher Nielsen <[email protected]>: > 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<[email protected]> 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 > >
