Home
The Toolkit for Online Communities
17104 Community Members, 0 members online, 2268 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Q&A : How to test Jerry's nsvhr/nsunix virtual hosting on development box? : One Message

Forum OpenACS Q&A: Response to How to test Jerry's nsvhr/nsunix virtual hosting on development box?

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.
And indeed, now things work beautifully!
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!!