Forum OpenACS Q&A: nsvhr /nssock/nsunix config

Collapse
1: nsvhr /nssock/nsunix config
Posted by Randy Kowell on 02/15/02 08:12 PM
I have a nsvhr nsunix/nssock solution up and running, my question is:
is there

any work around that would enble the URL to appear without having to
specify
the listing port? Since DNS does not support port re-direction, I
have run out

of gas. Perhaps I have configured it incorrectly?

Thanks,

Randy

Collapse
2: Response to nsvhr /nssock/nsunix config (response to 1)
Posted by David Walker on 02/15/02 08:20 PM
I am not sure I understand the question.

Are you referring to things like http://mysite:80/ and http://mysite/

Collapse
3: Response to nsvhr /nssock/nsunix config (response to 1)
Posted by Jonathan Ellis on 02/15/02 08:24 PM
sounds like you're missing something...  the whole idea with nsvhr is e.g. www.carnageblender.com and www.sfreview.org are invisibly processed by different nsd processes on the same IP.  You don't have to specify ports at all unless you want to connect to the "slave" nsd without going through the "master."
Collapse
4: Response to nsvhr /nssock/nsunix config (response to 1)
Posted by Randy Kowell on 02/15/02 08:59 PM
Yes. I have a master listing on port 80, a client listening on port 8080.
Two differnt config files running as separate process if I go to www.this
place.com:8080 I get the same contect as www.thatplace.com:8080 From a user
persective that is a show stopper. I need to have the user browse to
www.thatplace.com I have specified the port number in the /modules/nsunix
parameter as per the instruction I have followed. I know this can be done,
just can't fugure out where I went wrong. Any thoughts?

Randy
Collapse
5: Response to nsvhr /nssock/nsunix config (response to 1)
Posted by David Walker on 02/15/02 09:38 PM
You should configure the slave listeners for different ports.

Master should listen on port 80, as you have done.
The slave for www.thisplace.com should listen on one port, say 8080.
and the slave for www.thatplace.com should listen on a different port, say
8081.

http://www.thisplace.com:8080 and
http://www.thatplace.com:8080 should both display content for
http://www.thisplace.com

http://www.thisplace.com:8081 and
http://www.thatplace.com:8081 should both display content for
http://www.thatplace.com

and http://www.thisplace.com and http://www.thatplace.com should each
display the correct content.

Collapse
6: Response to nsvhr /nssock/nsunix config (response to 1)
Posted by Tilmann Singer on 02/19/02 07:00 PM
There seems to be some confusion about the purpose of nsunix and nssock here. This is all perfectly explained in Jerry's Virtual Hosting Howto.

If you go with what is called "Method One: nsvhr/nsunix" in the Howto, then there is no need for the slave servers to listen to any port at all - they will be connected to the master via a unix socket. Every user request goes through port 80 of the master server and therefore every user will only ever see port 80 on the master.

It's also possible to connect master and slaves via nssock - this is called "Method Two: nsvhr/nssock" in Jerry's Howto. In that case the slaves listen to some ports like 8001. The master server only needs to listen to external requests on port 80, and redirects the requests to the clients via the socket, e.g. 8001.

Collapse
7: Response to nsvhr /nssock/nsunix config (response to 1)
Posted by Randy Kowell on 02/19/02 08:07 PM
I have used the "HOWTO" as a guide, and have create master listening on port 80. I have also configured a slave with both nsunx and nssock. I can only get to the slave by specifing the port number (nssock seems to be working) If I tail the log files I see that nsunix is accepting connections, yet unless I use the port number in can not get to slave site. I get no errors in the log files, so I am at a loss. I can post a copy of my config file in the hopes someone will point out my error.

Randy

Collapse
8: Response to nsvhr /nssock/nsunix config (response to 1)
Posted by Tilmann Singer on 02/19/02 09:17 PM
Which method do you want to use to connect master and slave - nsunix or nssock?

Maybe we can help you if you post the ns/server/master/module/nsvhr/maps section of the master's config file and the relevant section of the client's config - either ns/server/slave/module/nsunix or ns/server/slave/module/nssock, depending on the method you chose.

Also make sure to take a look in the master's server log, not only in the client's. Any errors in virtual hosting redirection - e.g. a failed connection attempt to a unix socket - should be logged there.

Collapse
9: Response to nsvhr /nssock/nsunix config (response to 1)
Posted by Randy Kowell on 02/20/02 07:23 PM
I have choosen to use nsunix and nssock, perhaps that has been my mistake? I have all ther servers configed within a single file and start each server as new process: These are the snippets you may be able to help me with

#vhr-master
ns_section "ns/server/vhr-master/module/nsvhr/maps
ns_param "ottawamax.ca"    "unix://ottawamax.nsunix"
ns_param "www.ottawamax.ca"  "unix://ottawamax.nsunix"
ns_param  "vancouvermax.ca"      "unix://vancouvermax.nsunix"
ns_param  "www.vancouvermax.ca" "unix://vancouvermax.nsunix"

#ottm_cserver
ns_section "ns/server/ottm_cserver/module/nssock
ns_param port          8080
ns_param hostname  www.ottawamax.ca
ns_param address    192.168.20.32
ns_param timeout     0

#ottm_cserver
ns_section "ns/server/ottm_cserver/module/nsunix
ns_param hostname  "www.ottawamax.ca"
ns_parm socketfile   "ottawamax.nsunix"


Thank you,
Randy
Collapse
10: Response to nsvhr /nssock/nsunix config (response to 1)
Posted by Tilmann Singer on 02/22/02 07:05 PM
Please choose one way to connect the master with the client: either nsunix _or_ nssock. The recommended way would be nsunix, unless you have specific reasons to use nssock. Don't load the nssock module on the client servers at all, e.g. remove it from the ns/server/ottm_cserver/modules section, that should eliminate one possible cause for confusion. On the master, only load nssock, not nsunix. Of course you can later activate nssock on the client again, if you have the need to bypass the master by specifying a specific port number.

The config snippets you posted look ok - you just might want to add a mapping for each domain name with port 80 explicitely listed, like this to accomodate certain client programs (I think wget for example): 

ns_param "ottawamax.ca:80"    "unix://ottawamax.nsunix"

Also did you look in the master's log file? According to your server namings it's propably called server.vhr-master.log. Search it for occurences of the word nsunix and possible "connection failed" messages near it.

Collapse
11: Response to nsvhr /nssock/nsunix config (response to 1)
Posted by Jason Khong on 02/23/02 04:45 AM
I managed to get nsvhr/nsunix (method 1) running a couple hours ago. Try this:
Check the (serverroot)/modules/nsunix directory to see if the socketfiles are created correctly. You should see ottawamax.nsunix= and vancouvermax.nsunix= listed there. If you see anything else, check if your slave servers are loading the nsunix.so modules as "nsvhr" or "nsunix"... 
  ns_section ns/server/sopranos/modules
  ns_param   nsvhr                    ${bindir}/nsunix.so
as written in the howto, should instead be... 
  ns_section ns/server/sopranos/modules
  ns_param   nsunix                    ${bindir}/nsunix.so
A tiny typo by Jerry, which I think causes Aolserver to create the default socketfiles (ottawamax.nsvhr) instead of your specified socketfiles (ottawamax.nsunix).
I haven't tried using nsvhr /nsunix+nssock yet, will try it sometime soon :)
Collapse
12: Response to nsvhr /nssock/nsunix config (response to 1)
Posted by Randy Kowell on 02/26/02 04:56 PM
Jsaon,

You were correct, I was unaware of the socketfiles being dymaically generated. Every time I made a change to my .tcl file it was referencing an incorrect socketfile file. I moved all those file to a new location, corrected the .tcl file (I had hard coded the socketfile my mistake, started each server and voila, virtual hosting. I would like to thank everyone who contributed to this thread.
Thank you,

Randy