I'm trying to test a server setup of two sites (firstserver.org and secondserver.org) on a development box in an internal network with unrouteable ip addresses. Neither of these domain names is real, but I resolve them with appropriate entries in /etc/hosts with /etc/host.conf and /etc/nsswitch.conf set to resolve locally with files before dns. (I'm using DNS from the ISP, not running it locally--in case that matters.)

I've installed and patched AOLServer 3.3ad13 and I've amended the stock nsd.tcl file for each server only by editing the various items pointed out in Jerry's document. AOLServer serves pages from either site when I start either one alone via nssock. I thus know that AOLServer works and the name resolution works. When I set up the third master server (running nsvhr) and start the two "slave" processes (using the nsunix module instead of the nssock module), it *appears* that the three processes seem to work (though they don't):

• I see the appropriate firstserver.nsunix and secondserver.nsunix socket files in /usr/local/aolserver/modules/nsunix.
• In standard out during the master server startup, I see notices that nsvhr is redirecting each of the mapped domains to the appropriate nsunix socket file.
• However, earlier in the startup process for each slave server, I see in standard out: "Warning: nsunix: missing Location and Port parameters". (However, I do have the default port 8000 set in each case.)
• Nevertheless, later on in standard out during each slave server startup, I can see "Notice: nsunix: DrvStart starting: listenSocket = 12, modules/nsunix/firstserver.nsunix" for one and "Notice: nsunix: DrvStart starting: listenSocket = 12, modules/nsunix/firstserver.nsunix" for the other (suggesting that some default has kicked in to provide the missing Location and Port parameters??) However, both slave servers appear to have been given somehow the same listenSocket (=12) (Is this correct; seems unlikely.)
• One other confusing clue is that I don't see separate server.log files in /usr/local/aolserver/log/ even if I include a path in the ns_section "ns/parameters" section. In fact, no logs are getting written by any of the servers. What can this mean?

Anyway, when I then try to hit either slave server with a browser on the same server box, I get the error "Netscape's network connection was refused by the server www.firstserver.org:8000. The server may not be accepting connections or may be busy."

If this is a simple config problem, I can't spot it after staring at things for a long time. So here are my questions:

• Are there additional parameters I'm supposed to give the nsunix module in each of the slave server's startup .tcl files (I'm using separate "nsd.tcl" files for each of the three servers.)? I'm just using the ones Jerry indicates:

     ns_section "ns/server/${servername}/module/nsunix"
     ns_param hostname www.firstserver.org
     ns_param socketfile firstserver.nsunix
  

• Is this some problem with how I'm trying to dodge DNS by using /etc/hosts in this manner? How do the rest of you handle this when working on sites on development boxes that you then mirror up to your real servers? To date I've done all my development on the live site, but this obviously isn't a good long-term approach.
• What else am I'm missing?
• Would someone be willing to post their "nsd.tcl" files if they've set them up separately for the master server and slave servers?
Many thanks for any pointers!

Stan

Looks like nssock of the master server is not correctly configured. Does it say nssock: listening on port xxx as desired after startup?

Doh. No it doesn't, and the reason (I'm completely embarrassed to admit) is that I'd somehow commented out nssock in the ns/server/${servername}/modules section. Here I was looking at the slave config files and the problem was in the master file. Isn't that always the way it is?

Do you want the master server to listen on port 80 or on port 8000? If it listens on 80 then you should be able to request www.firstserver.com and www.secondserver.com, if it listens on 8000 then it should answer on www.firstserver.com:8000 like your wrote above, but I wonder what the point of this would be, since the only benefit of virtual hosting is that you can leave out the port number. Otherwise you could just setup localhost:8001 for your first test server and localhost:8002 for the second, without the need for a master server and nsvhr.

You are of course correct, and it was my intent to run everything on standard port 80. I just left things at 8000 "to keep it simple". Yeah, right. Too simple by half!

When the master is correctly accepting connections then it should at least answer your request, even if it cannot connect to the slave server for whatever reason. You would get a 404 Not Found or custom error page if configured, but never a connection refused.

There is an additional Port parameter in my setup:

     ns_section "ns/server/${servername}/module/nsunix"
             ns_param Port 80
             ns_param hostname "bla" 
             ns_param socketfile "bla.nsunix"

I have no idea where it comes from nor what it does, besides generating the above warning if you leave it out (i just tried that).

Excellent! This addition stops the warning just as you say!

About the log files not being written: maybe you are running with the -f option? The server log seems not to be written in foreground mode.

Once again you are correct.

Tilmann, you are a gentleman and a scholar! Many thanks!!

Nsvhr/nssock will take you 95% of the way there and you won't encounter any of the weirdities involving unix domain sockets and where the unix domain socket is placed in the directory, or any of that other crap required to configure the damn thing.  It's probably fast enough for your needs for quite a while, and it gives you a fallback position to take anytime you think my dubious patches are more dubious than usual.

That fallback position is a valuable thing to have, or rather it's a valuable thing for me if you have it.  It lets you differentiate bugs I've introduced into your system from bugs you introduced into your system and thus lets me get on with work of creating more GPLed bugs.

Tonight on Chin Wag, Theater Daniel Pinkwater said that it is just a myth that a polar bear's white fur acts like fiber optics in directing/trapping/channeling solar energy.  It's now been measured and it isn't true.  And underneath that white fur is black skin.  Go figure.

Nsvhr/nssock will take you 95% of the way there and you won't encounter any of the weirdities involving unix domain sockets and where the unix domain socket is placed in the directory, or any of that other crap required to configure the damn thing. It's probably fast enough for your needs for quite a while, and it gives you a fallback position to take anytime you think my dubious patches are more dubious than usual.

Jerry, is this just your usual endearing modest understatement of your formidable technical achievements, or are there limitations that one runs into with the nsvhr/nsunix solution?

• Does it choke at high levels of throughput?
• Does it not work with SSL?
• Is the IE 5 bug a commonly-encountered problem?
If it works, it works, isn't that right?

Anyway, my hat's off to you for this major contribution you've made to the community! I particularly like the nsvhr/nsunix approach because

• It's wonderfully modular; to add a domain/site, you add a new config file in /usr/local/aolserver, a new pageroot for the OpenACS code, and a new PG DB, and you're golden.
• You can start and stop each site separately.
• You can use the same procedures to migrate new sites to a new box if things get busy as you do to add the second site to an idle box (and the fewer ways I have to learn to do something, the better).
What's not to love about that?

• Master server (http://openacs.org/new-file-storage/one-file?file_id=325)
• Slave server (http://openacs.org/new-file-storage/one-file?file_id=327)
These seem to work for me. They're the stock nsd.tcl file that comes with AOLServer without the OpenACS mods but with Jerry's mods. I presume that once I add all the other OpenACS stuff, things will still work.

Hope this saves someone some time. (Like me next time when I need to do this again and can't remember how I did it.

That's why the fact I can't figure how to solve the IE POST bug is so annoying.