As you wrote there is no need for service disruption.
The old method I have used was to actually spawn a second squid while
reloading but it seems like a very messy solution.
I think that for an ISP solution there should be 0 fault tolerance since
the service should give answer to hospitals and other life related
services that should not be disrupted by an admin which doesn't now
about when and why he does the update or upgrade.
The admin should from my point of view do what ever needed for this
specific task and not rely on the split second which a miracle will
serve this small kid who the social worker is just handling now.
I do hope my words was understood as a compliment to all the related
amazing guys who worked and works days and nights.
Eliezer
On 6/9/2013 7:46 PM, Squidblacklist wrote:
On Sun, 09 Jun 2013 13:34:11 -0300
Marcus Kool <marcus.kool@xxxxxxxxxxxxxxx> wrote:
On 06/09/2013 12:59 PM, Alex Rousskov wrote:
On 06/09/2013 03:29 AM, Eliezer Croitoru wrote:
Would you prefer a filtering based on a reload or a persistent DB
like mongoDB or tokyo tyrant?
I would prefer to improve Squid so that reconfiguration has no
disrupting effects on traffic, eliminating the "reload is
disruptive for Squid but not for my ICAP service" difference.
There are many important differences between ACL lists, eCAP
adapters, and ICAP services. Reconfiguration handling should not be
one of them.
Eliezer seems to be concerned about what happens during
reconfiguration, and he has a point.
A Squid reconfigure simply stops the web proxy service for some time,
while a reconfigure of a 3rd party component (URL redirector, ICAP
or other helper) _may_ not cause a disruption of service.
Therefor I would never use the filter-with-squid-acls option (ok, I
am biased but ufdbGuard reconfiguration does not interrupt the proxy
service and some admins reconfigure it often during working hours).
Although one can schedule to do a reconfigure at 3 AM when disruption
of service should not be a problem there are always the small or big
problems that appear during working hours and need an immediate
configuration change.
There is no reason for service disruption for a competent
administrator. For every problem there is a solution. See my response.
I just got done testing both methods, and they work.
And yes, improve Squid to have no service disruption during a
reconfigure will be a great feature.
Are you aiming at "minimise service disruption window" or go for
"never disrupt service" (unless a very important parameter like port
number changes).
Marcus
-
Signed,
Fix Nichols
http://www.squidblacklist.org
