2009/8/21 Noah Evans <noah.ev...@gmail.com>: > Hey Devon, > > 1. Others know more about that than I do. Wait a bit, that problem > might get solved.
I think I brought that up because if anybody has ideas about fixing them or making them better, I would like to do that. > 2. drawterm tends to hang on secstore for me. Try a bogus -s option or > use a p9p secstore/factotum and see what happens. I'm not sure I have secstore set up. Perhaps that's it? > 3. what's stopping you from setting up your external network as the > one on /net.alt and using dhcp internally? Or booting tcp off the file > server without dhcp? e.g. baking it into plan9.ini, or entering it > manually at boot time? I've tried similar tricks to yours using > inferno and getting cute and breaking the convention of /net.alt for > external networks has always ended in a world of pain. Tried to explain that. I just don't want to due to the number of hours I've spent trying to configure it this way :). I think Christopher's suggestion is what I'll do next; I totally forgot that was possible. --dho > Noah > > On Fri, Aug 21, 2009 at 11:07 PM, Devon H. O'Dell<devon.od...@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 >> >> > >
