Two websites on one Win2k server?
September 15, 2008 4:49 PM Subscribe
Is there a way to run two "virtual" websites on a Windows 2000 server that are accessible to different users by different names?
We have a VB6 application that's based on a SQL Server backend. In addition to the forms within the application that are used to review and change the data, there's also a webserver involved that serves up VBScript pages (mostly reports). This is all done solely on an internal network with a Win2k server running IIS 6. What I'm trying to do is set it up so that two users who are testing will be working against totally independent instances of the database.
The DSN is hard-coded into the application, and (for the sake of this question) can not be changed; the DSN (Application_Data) is obviously configured on each client machine, but is also set at the server for the sake of the ASP pages that need to access the data. The "web address" of the web server is also (for the sake of this question) not changeable -- it's hard-coded into the application as http://application, and we set up an entry in users' HOSTS file mapping "application" to our server address (192.168.0.254).
I've created a second instance of the database in SQL Server (DB1 now has a duplicate, named DB2). I've set up a second DSN on the server (Application2_DSN) which references DB2. I've copied over the web directory to a second directory on the server (wwwroot2), and changed all of the files in it which referenced the old DSN to the new DSN. I then set up a new "Web Site" in IIS pointing to wwwroot2.
It's at this point that I get stuck. What's the final step I need to do so that user A, when they navigate to http://application, go to one IIS "Web Site," while user B would be directed to another "Web Site?"
Our router is set up to direct all incoming port 80 requests originating on our network to the server 192.168.0.254. I've tried setting it up to also forward all port 8080 requests to the same server, and then configuring the second website in IIS to listen on port 8080, and that almost works (going to 192.168.0.254:8080 in a web browser brings up the second "website") but it doesn't entirely work because apparently you can't specify a port number in a HOSTS file (grrr), so I can't modify the entry in the HOSTS file to point to 192.168.0.254:8080 instead of 192.168.0.254.
If I've left out any crucial details, please don't hesitate to ask for clarification.
We have a VB6 application that's based on a SQL Server backend. In addition to the forms within the application that are used to review and change the data, there's also a webserver involved that serves up VBScript pages (mostly reports). This is all done solely on an internal network with a Win2k server running IIS 6. What I'm trying to do is set it up so that two users who are testing will be working against totally independent instances of the database.
The DSN is hard-coded into the application, and (for the sake of this question) can not be changed; the DSN (Application_Data) is obviously configured on each client machine, but is also set at the server for the sake of the ASP pages that need to access the data. The "web address" of the web server is also (for the sake of this question) not changeable -- it's hard-coded into the application as http://application, and we set up an entry in users' HOSTS file mapping "application" to our server address (192.168.0.254).
I've created a second instance of the database in SQL Server (DB1 now has a duplicate, named DB2). I've set up a second DSN on the server (Application2_DSN) which references DB2. I've copied over the web directory to a second directory on the server (wwwroot2), and changed all of the files in it which referenced the old DSN to the new DSN. I then set up a new "Web Site" in IIS pointing to wwwroot2.
It's at this point that I get stuck. What's the final step I need to do so that user A, when they navigate to http://application, go to one IIS "Web Site," while user B would be directed to another "Web Site?"
Our router is set up to direct all incoming port 80 requests originating on our network to the server 192.168.0.254. I've tried setting it up to also forward all port 8080 requests to the same server, and then configuring the second website in IIS to listen on port 8080, and that almost works (going to 192.168.0.254:8080 in a web browser brings up the second "website") but it doesn't entirely work because apparently you can't specify a port number in a HOSTS file (grrr), so I can't modify the entry in the HOSTS file to point to 192.168.0.254:8080 instead of 192.168.0.254.
If I've left out any crucial details, please don't hesitate to ask for clarification.
It's at this point that I get stuck. What's the final step I need to do so that user A, when they navigate to http://application, go to one IIS "Web Site," while user B would be directed to another "Web Site?"
Are you saying that you want the two users to use the same URL to access two different websites? If so, make it easy on yourself and give them different names.
Otherwise, it sounds like you're just trying to do name-based virtual hosting to run two different sites off the same IP. The web server will look at the request coming from the user, see "http://app1" or "http://app2" and route the request accordingly.
posted by rhizome at 5:59 PM on September 15, 2008
Are you saying that you want the two users to use the same URL to access two different websites? If so, make it easy on yourself and give them different names.
Otherwise, it sounds like you're just trying to do name-based virtual hosting to run two different sites off the same IP. The web server will look at the request coming from the user, see "http://app1" or "http://app2" and route the request accordingly.
posted by rhizome at 5:59 PM on September 15, 2008
Response by poster: Hm, that's an interesting idea. I'll give that a try tomorrow; if anyone has any other suggestions, please let me know.
posted by Doofus Magoo at 6:01 PM on September 15, 2008
posted by Doofus Magoo at 6:01 PM on September 15, 2008
Response by poster: Rhizome -- let's assume for the sake of this question that I can't give the sites different names. The address of the site is hard-coded into the VB6 application, and while we could easily create two different versions of the app (one for each website address), we've gone that route before and it quickly becomes a nightmare to maintain.
posted by Doofus Magoo at 6:22 PM on September 15, 2008
posted by Doofus Magoo at 6:22 PM on September 15, 2008
" What's the final step I need to do so that user A, when they navigate to http://application, go to one IIS "Web Site," while user B would be directed to another "Web Site?"
The final step to do what you're trying to do, based on the constraints you outline, is to deploy a reverse proxy in front of the web box that implements these rules based on whatever you use to distinguish "user A" and "user B" -- be that IP address or authentication tokens or however you define "user." Those rules can be as complex or as simple as you need them to be.
An alternative for definitions of "user" equivalent to "any person who sits at a given computer" is to set up address-based virtual hosting and modify the hosts file on systems that comprise "user B". That's harder to maintain in the long run due to the administrative headache, and I'd suggest avoiding it if you can.
"The DSN is hard-coded into the application, and (for the sake of this question) can not be changed; the DSN (Application_Data) is obviously configured on each client machine, but is also set at the server for the sake of the ASP pages that need to access the data. "
This is, by the way, a really badly designed application (despite being typical of corporate internal software development). Make sure whoever did it never makes things for production use again.
posted by majick at 7:52 PM on September 15, 2008
The final step to do what you're trying to do, based on the constraints you outline, is to deploy a reverse proxy in front of the web box that implements these rules based on whatever you use to distinguish "user A" and "user B" -- be that IP address or authentication tokens or however you define "user." Those rules can be as complex or as simple as you need them to be.
An alternative for definitions of "user" equivalent to "any person who sits at a given computer" is to set up address-based virtual hosting and modify the hosts file on systems that comprise "user B". That's harder to maintain in the long run due to the administrative headache, and I'd suggest avoiding it if you can.
"The DSN is hard-coded into the application, and (for the sake of this question) can not be changed; the DSN (Application_Data) is obviously configured on each client machine, but is also set at the server for the sake of the ASP pages that need to access the data. "
This is, by the way, a really badly designed application (despite being typical of corporate internal software development). Make sure whoever did it never makes things for production use again.
posted by majick at 7:52 PM on September 15, 2008
Response by poster: majick: It's an application we inherited from the previous contractor. Is there something beyond the use of DSNs that sets off red flags for you?
posted by Doofus Magoo at 3:22 AM on September 16, 2008
posted by Doofus Magoo at 3:22 AM on September 16, 2008
This: " a webserver involved that serves up VBScript pages (mostly reports)"
This: "The DSN is hard-coded into the application"
This: " but is also set at the server for the sake of the ASP pages that need to access the data"
This: " The "web address" of the web server is also (for the sake of this question) not changeable"
And this: "let's assume for the sake of this question that I can't give the sites different names."
A web application should be easily configurable and content to live at pretty much any URL, using any appropriate back end. If the web portion of the application is pseudo-integrated into the fat client, then the fat client should be passing information to it that indicates what database the current fat client session is using. If it's not, then the web user should just be able to pick the appropriate URL.
Abstracting out the choice of server instance and database to a DSN is exactly the wrong thing to do when both the fat and web clients have a reasonable need to coordinate their activities. Why not just read a list of available back ends from the web server, then have the fat client build a connection string?
More generally speaking, the constraints you seem to be put under by the way this thing is cobbled together give off strong cluelessness signals. If it's really this hard to have multiple instances of the application in existence, how exactly did the "previous contractor" propose to validate system changes and test deployment procedures, let alone scale the thing or allow multiple production instances? If it's this hard to do basic administrative and testing procedures now, chances are it was never even considered during the design and construction phases.
I'm guessing what's in place now was constructed in place, with no development process and changes done in production on the fly. More to the point, the whole thing sounds clunky and amateurish if you're under such ridiculous constraints. Yeah, that's not someone I want crafting systems my business depends on.
posted by majick at 6:09 AM on September 16, 2008
This: "The DSN is hard-coded into the application"
This: " but is also set at the server for the sake of the ASP pages that need to access the data"
This: " The "web address" of the web server is also (for the sake of this question) not changeable"
And this: "let's assume for the sake of this question that I can't give the sites different names."
A web application should be easily configurable and content to live at pretty much any URL, using any appropriate back end. If the web portion of the application is pseudo-integrated into the fat client, then the fat client should be passing information to it that indicates what database the current fat client session is using. If it's not, then the web user should just be able to pick the appropriate URL.
Abstracting out the choice of server instance and database to a DSN is exactly the wrong thing to do when both the fat and web clients have a reasonable need to coordinate their activities. Why not just read a list of available back ends from the web server, then have the fat client build a connection string?
More generally speaking, the constraints you seem to be put under by the way this thing is cobbled together give off strong cluelessness signals. If it's really this hard to have multiple instances of the application in existence, how exactly did the "previous contractor" propose to validate system changes and test deployment procedures, let alone scale the thing or allow multiple production instances? If it's this hard to do basic administrative and testing procedures now, chances are it was never even considered during the design and construction phases.
I'm guessing what's in place now was constructed in place, with no development process and changes done in production on the fly. More to the point, the whole thing sounds clunky and amateurish if you're under such ridiculous constraints. Yeah, that's not someone I want crafting systems my business depends on.
posted by majick at 6:09 AM on September 16, 2008
« Older Is there an offline Blackberry city guide? | What does the Bank of America purchase of Merrill... Newer »
This thread is closed to new comments.
posted by MCTDavid at 5:55 PM on September 15, 2008