Hi,

Please consider ing with this apache / reverse proxy issue.


A company has some servers, serving a production web site and
an administrative interface. Presently, the servers are load
balanced using IPVS, so the requests from browsers are delivered
to apache with the genuine source ip address of the request.

The admin interface - we'll say is at http://website.com/tools/

The admin interface is locked down by both user/password credentials
and also limited to a range of ip addresses using Allow from
directives in httpd.conf, e.g. :

<Location /tools>
Order deny,allow
Deny from all
Allow from 127.0.0.1
Allow from 10.0.1
Allow from 1.2.3.4
</Location>


The company are now looking to use a reverse proxy, to replace the
IPVS equipment to balance the requests. The reverse proxy sets
an additional header - we'll say that it is called 'xyz' - with the
original ip address of the client.

(The reverse proxies are not running on the same physical hardware
as the web servers)

There are places that this header will be useful - e.g. the company
can still produce a combined log by replacing '%h' with '%{xyz}' in
a LogFormat directive - but the company want to use the details in
this 'xyz' header to authenticate the location of users in Allow
from config options.

i.e. we want the same list of IP addresses in the <Location> tags,
but we want apache to look at a header for the IP info, not the
source requests (which will always be the reverse proxy.)


Any ideas on how this can be done ?

Many thanks for any you can offer,
Andy





--
http://fotoserve.com/ - Prints, Slides, Posters, Mugs, T-shirts,,
Calendars, Jigsaws, Tableware, Caricatures, Greetings cards, Picture
bags, Photo Album and Book covers, Canvas Prints, tissues and more
..... from your own digital images.

Andy Davidson <$andy$@nosignal.org> writes:
> i.e. we want the same list of IP addresses in the <Location> tags,
> but we want apache to look at a header for the IP info, not the
> source requests (which will always be the reverse proxy.)
>
> Any ideas on how this can be done ?

Look up mod_rpaf for Apache. This rewrites the remote address to be
the address in the header, *if* the original remote address is in a
trusted list.

It (in Apache 1, at least - I didn't look at the Apache 2 version) is
a very large hack, so there may be side-effects, but we managed to run
it in production for several months without serious problems. There
were other authentication-related issues, but provided you *only*
proxy and don't cache too, they won't bite you.

--
Chris

[Chris Morris wrote in comp.infosystems.www.servers.unix]
> It (in Apache 1, at least - I didn't look at the Apache 2 version) is
> a very large hack, so there may be side-effects, but we managed to run
> it in production for several months without serious problems. There
> were other authentication-related issues, but provided you *only*
> proxy and don't cache too, they won't bite you.

Thanks for your incredibly quick reply.

Cacheing is in the wishlist of good things to have the proxies doing -
if we can limit the number of requests as well as balance requests, then
this is perfect, but I will certainly take a look.

Do you remember what you saw with cacheing ?



Cheers
Andy




--
http://fotoserve.com/ - quality printing for digital photos.

Andy Davidson <$andy$@nosignal.org> writes:
> [Chris Morris wrote in comp.infosystems.www.servers.unix]
> > It (in Apache 1, at least - I didn't look at the Apache 2 version) is
> > a very large hack, so there may be side-effects, but we managed to run
> > it in production for several months without serious problems. There
> > were other authentication-related issues, but provided you *only*
> > proxy and don't cache too, they won't bite you.
>
> Thanks for your incredibly quick reply.
>
> Cacheing is in the wishlist of good things to have the proxies doing -
> if we can limit the number of requests as well as balance requests, then
> this is perfect, but I will certainly take a look.
>
> Do you remember what you saw with cacheing ?

General issues:

Make sure you send the appropriate no-cache or private-cache-only
headers with any page that requires authentication. This should happen
automatically with Basic authentication, but in our case we had a set
of pages where either using Basic auth or coming from a particular IP
block was sufficient to authenticate - and those needed explicitly
setting to only private caching.

Depending on how aggressively you cache, you may need to let your
local web developers know about the force-reload command in their
browser.

mod_rpaf sometimes gave bad entries in the hostname if there was a
keepalive connection. I *think* this only happened when we put two
reverse proxies in series, but I could be wrong. This was a while ago
and I can't remember the details.

Make sure all your Last-Modified, Expires, etc headers are in GMT
timezone.

Obviously, if you're using multiple back-end machines, make sure that
they're always synchronised or the reverse proxy might end up
assembling a page from a range of components. This is more likely if
you're using caching.

Apache mod_proxy specific issues:

If you use apache's mod_proxy, you might want to experiment with other
cache cleanup routines. We found that fastrm (from the NNTP daemon) on
any cache file with an access time more than N hours ago was more
effective than mod_proxy's own cache cleanup routines. YMMV there.

There at least was a bug in Apache mod_proxy that corrupted the cache
copy if the original response had a header line longer than 4096
bytes. Never caused a problem in practice for us but I don't know what
you put in the headers on your system.

--
Chris