I came across Pound while looking for a simple way to upgrade web
applications seamlessly. I'd like to be able to stop Pound from forwarding
any further new sessions to a specific back end, but continue to forward any
existing session requests to that back end, the idea being that the sessions
will eventually expire, and upgrades/maintenance can be carried out before
enabling it again.

I've worked through the archive and found nothing that relates to this. I
imagine that this would be a fairly common requirement of people running web
applications, so if it's not a feature of Pound, I thought I'd ask to see if
there are there any technical obstacles that might make it difficult for me
to add?

Since I can trust internal networks, I thought that controlling this using
http requests to an internal interface would suffice; just to enable and
disable back-ends, and perhaps to list active sessions that are still bound
to each disabled back-end.

Any thoughts on this would be appreciated.

Thanks,

Kevin

On Saturday 04 December 2004 18.06, Kevin Sangeelee wrote:[...]

Sorry, Kevin, but this is not supported. Pound allows you to control taking a 
server off- (and back on-) line, but without waiting for sessions to become 
inactive.

The main problem, in case you want to add the feature, would be what to do if 
the server goes down. Should further requests be directed there just because 
there is a session?[...]

On Mon, Dec 06, 2004 at 09:27:31PM +0100, Robert Segall wrote:
[...]

I'd suggest that the use of sticky sessions implies that a session is only
valid in the context of the originating server, and so there's usually no
point in trying to forward the request to any other server. However, this
isn't necessarily going to be true for all situations, so I imagine it would
need to be configurable per URL group (either forward to a new server, or
persevere with the old).

In the case where the URL group has been configured to persevere and a
disabled server is also down, the response that would be returned would be
the same as that returned when Pound runs out of active back ends during
normal load balancing (whatever that may be).

On a slightly more technical note, does anyone have suggestions on the best
way to communicate with a running Pound process? I can't help thinking that
intercepting the http/https requests on a specified interface is a little
bit crass, but it does seem temptingly simple.

Kevin

On Tuesday 07 December 2004 02.03, Kevin Sangeelee wrote:[...]

Interesting idea - we'll keep it in mind for future stuff.
[...]

Error 503 - Service unavailable.
[...]

What is it you want to accomplish?[...]

On Wed, Dec 08, 2004 at 12:26:37PM +0100, Robert Segall wrote:
[...]
[...]

First, let me be clear that I'm aware that Pound doesn't have the features
I'm discussing, and that I'm considering modifying it to meet my needs.

I want to tell the running Pound process that I want to disable BackEnd x
from receiving any new sessions. Similarly, I'd like Pound to be able to
tell me what session (or just how many) are still active on BackEnd x.

So, with HTTP, for example, from the same server that Pound is running,
where a ListenHTTP is configured with 127.0.0.1,80, I might say something
like: -

 web(at)proxy:~$ wget -O - http://localhost/DisableBackEnd?ip=192.168.0.10
 pound disabled ip 192.168.0.10 for any new sessions

 web(at)proxy:~$ wget -O - http://localhost/ListSessionsBackEnd?ip=192.168.0.10
 pound session abc123, type cookie, ttl=1000s
 pound session xyz123, type cookie, ttl=150s

 web(at)proxy:~$ wget http://localhost/EnableBackEnd?ip=192.168.0.10
 pound enabled ip 192.168.0.10 to accept new sessions

This is the simplest way I can think of to control Pound, because I can
mostly use what's already there (i.e. intercept the request when it arrives
on a listening socket). Does that seem sensible enough?

Kevin

On Wednesday 08 December 2004 17.31, Kevin Sangeelee wrote:[...]

Seems sensible, but I am worried about two issues:

- having this sort of "special" requests may cause problems for innocent users 
(sooner or later someone will have an application that has DisableBackEnd as 
part of its URL), and they add significant complexity to the program 
(intercepting and identifying the special URLs, generating the response 
pages).

- security may be a problem - you are essentially allowing anyone to control 
your proxy by simply requesting an URL. Not a very good thing, at least in my 
view (and besides, Apsis is a security company).

Now two of the three functions you want are already available through the 
HA_port mechanism: create a small program that listens on the HA_port. As 
long at it accepts connections Pound considers the back-end to be up, 
otherwise the back-end is "dead". This allows you to take servers off-line 
and bring them back in a controlled manner, and is exactly why we created the 
HA_port mechanism.

It looks to me like the only thing missing from your wish-list is the sessions 
report. Is it really important enough to warrant all the extra complexity? 
What exactly would you use it for? Could the netstat output be enough (just 
shows you the active connections)?[...]