设置虚拟主机文件以托管来自远程服务器的源代码

Question

I would really appreciate your support for the below inquiry

Current Situation:

I have a web app (contains a module to upload documents) on a Linux Apache server "A" that can only be HTTP-ed through the intranet.

Required:

Another Linux Apache server "B" is required to host the same web app, while maintaining the source code on server "A" only. Server "B" can be HTTP-ed through the internet and intranet.

Blocking points:

Under the current circumstances we are unable to host the website on server "B" directly (which would seem like the logical solution).

Question:

Is it possible to setup the virtual-hosts of the httpd.conf file for such requirement?

Research:

Usually most of my findings were posts about deploying a load-sharing/load-balancing solution ( not my objective ), or setup a two-way synchronization process between "A" and "B" (last resort solution).

Googled strings:

share website between two servers, host website on two servers, virtual host to another server, run single website on multiple servers setup, virtual host for website on another server, host a website on two different servers, setup two linux servers to host the same website

Server Details:

Server A:

• Server IP: 192.168.xxx.xxx (accessible through the intranet only)

• Hosts the website source code

• Apache server

• OS: RHEL5

Server B:

• Accessible through the intranet and internet

• Apache server

• OS: Same as A (RHEL5)

Answer 1

Summing up what you've probably found yourself by now: unfortunately, there are two things that are called proxying. The you are interested in is called a reverse proxy , in which B will take requests and forward them to A. The client never sees that A even exists. There are few security concerns, depending on what angle of security you look at:

1. server A only ever sees requests from B, not the original client, so any IP-based restrictions you want should be configured on server B.

2. The usually mentioned security concern is that a ( forward ) proxy will ask arbitrary servers for things on behalf of the client, so it masks the client's identity. I don't think you need to worry about this as long as you put ProxyRequests Off to disable forward proxying.

3. Server A might accidentally reveal its IP, which you might not be comfortable with. When B passes back the answer to the clients request that it has received from A, it will not look at the payload. So, if you return HTML documents, they better all have only relative paths. I think this might be the problem you are having: if your code still contains references to 192.168.xy, those won't work for the external client. If you are changing paths (ie you have something like ProxyPass /somepath http://internal-server/otherpath ), things become even more complicated, so try to avoid that. (In general, your backend application would need knowledge of what its publicly-visible URIs are. How to do this depends on the application.)