Re: Redundancy

> Lately, I've been encountering a loss-of-confidence in the proxying
> system whenever it becomes unavailable for any reason. Such reasons
> include: System maintenance, the short delay while doing a '-k
> reconfigure', log rotation, and the periodic shutdown (to tidy up memory
> usage)..not to mention the occasional fault that causes the box to
> become unavailable (particularly infrequent, but such things _do_
> happen).

> These things cause all manner of griping, but more importantly, it
> causes people to clear their proxy configurations, and bypass the
> system. Now, we don't want to _force_ people to use them, because
> occasionally you come across an object that just doesn't load properly
> through a proxy (often these have some kind of security doodad that
> looks back at the source-ip), and we don't want to unduly restrict the
> users in this regard. However, any kind of interruption of service
> causes the users to clear their browser's proxy settings, and they don't
> remember to put them back later.

Yup. I struggle with that same issue frequently. I try and do all my
maintenance at weird times, but inevitably something still goes wrong...

Idea: What if your program sat on the squid cache port (3128) and listened
to requests- forwarding them to localhost or another parent if necessary.
The connection shell, or whatever you'd call it, could run always, but if
you had to take squid down for maintenance things would keep moving.

As is, I would be interested in seing it.

                                        -keith

>
> I thought about that a _lot_ this afternoon, and sat down and wrote some
> code. The end-result is 'sparent 1.1'. It accepts connections. It
> doesn't fork. It uses less than 30K of memory, and can be configured as
> a sole parent for squid (it only listens to localhost). When it gets a
> connection, it tries to forward it to (in turn) each of (up to) five
> parents. If a connection succeeds, sparent will forward the connection
> traffic through it. If all of them fail, it returns a (somewhat)
> customisable HTTP/1.0 error message, and sends an email to the
> configured administrator, telling them that the link is down (I found it
> a handy feature). Since it's dumb forwarding between connections, it
> doesn't care if they're persistant or not. It's happy with either.
>
> It's evil. It's scummy. It's beta. It has no real documentation. Just a
> small source file, and a sample config. It also works, within the limits
> of my testing. If you're interested, let me know, and I'll bounce a copy
> of it out to you.
>
> TODO:
> Give connection failure some smarts so that it doesn't email you _every_
> time someone tries to connect and everything's unreachable.
> Find bugs.
> Fix bugs.
>
> D
>
> --
> Note to evil sorcerers and mad scientists: don't ever, ever summon
> powerful
> demons or rip holes in the fabric of space and time. It's never a good
> idea.
> ICQ UIN: 3225440
>
>
Received on Thu Nov 06 1997 - 05:22:51 MST