Re: Email Alert Proposal
Hi Simon, On Wed, Jun 25, 2014 at 01:27:51PM +0900, Simon Horman wrote: (...) > > We had such an idea in the past, however the principle was to use the > > address of a smart relay host. We cannot use a command because the process > > is supposed to be chrooted. > > Thanks, if that is the direction you wish to take things then I'm happy to > do so. I guess a simple SMTP client is not an insurmountable challenge. But > I wonder if there is any infrastructure in haproxy that might make such an > implementation easier. If so, could you point me at it? Yes, please look at two things : - tcp-check - peers tcp-checks can already be used to send complete e-mails, they act on steps, are woken up every time something changes, etc... And since you've worked with health checks, it's probably an area you'll be more familiar with. Peers are made of a client that gets woken up by other tasks to send their contents to the other side. Looks at src/stick_table.c:stktable_touch() and at its call from src/session.c:process_store_rules() to get an idea. I think your use case is very close from these two above combined. > > Also, in my opinion the SMTP relay should be > > per section (ie: supported in the defaults section) because in shared > > environments, customers want to use a different gateway and e-mail > > settings. > > Yes, I agree that sounds like a good idea. > > > In fact in the ALOHA we have implemented a daemon which watches > > the unix socket to send e-mails because by then it was too much work to > > implement it natively. Now it should be much simpler. > > I'm clad to hear it will be simpler though I'm not sure that I understand > why this is so. Because we wanted to do this at times of version 1.3 or so, when it wasn't possible to have independant tasks living their own life as we have now (eg: peers & checks). > I would prefer to only handle plain-text to start with. Yes, sure that will be enough for a start. > To allow a working prototype to be slightly closer to hand. > But I agree that SSL support, I assume in the form of STLS, > is an important feature. STARTTLS can be more difficult to implement, as it requires switching the connection's protocol once it's already established and communicating. I'd expect a number of surprizes there. But sending over TLS to port 465 should be very easy (again, see how tcp-check currently deals with this : if check-ssl is set, then the whole connection is made over SSL/TLS). Do not hesitate to ask if you find anything that's unclear ! Cheers, Willy
Re: Mixed-mode frontend
By the way, the ssl option for the server did the trick. Based on the
documentation for the frontend mode option ("tcp ... This is the default
mode. It should be used for SSL, SSH, SMTP, ...") I had assumed that no
such backend option was available. But I'm glad I was wrong!
Thanks again, Baptiste!
On Wed, Jun 25, 2014 at 3:49 PM, Claus Strommer
wrote:
> Whoops!
>
> Just to be safe, here's the whole thing again, with additions
>
>
> 8< snip
> frontend httpweb
> bind *:80
> bind *:443 ssl crt /etc/ssl/private/primal_bundle_2014.pem
> mode http
> option httplog
>
> acl host_about hdr_end(host) -i about.site.com
>
> acl host_api hdr_end(host) -i api.site.com
> acl require_ssl hdr_end(host) -i api.site.com
>
> acl host_error hdr_end(host) -i error.site.com
> acl require_nossl hdr_end(host) -i error.site.com
>
>
> redirect scheme https if !{ ssl_fc } require_ssl
> redirect scheme http if { ssl_fc } require_nossl
>
> use backend about:3000 if host_about
> use backend api:80 if host_api
> use_backend nginx:8080 if host_error
>
>
>
> backend about:3000
> mode http
> balance roundrobin
> option httplog
> #option httpclose
> option forwardfor
> server about.backend.com about.backend.com:3000 check inter 5000
>
> backend api:80
> mode http
> balance roundrobin
> option httplog
> #option httpclose
> option forwardfor
> server api.backend.com api.backend.com:80 check inter 5000
>
> backend about:3001
> mode http
> balance roundrobin
> option httplog
> #option httpclose
> option forwardfor
> server about.backend.com about.backend.com:3001 check inter 5000
>
> backend nginx:8080
>
> mode http
> balance roundrobin
> option httplog
> #option httpclose
> option forwardfor
> server localhost localhost:8080 check inter 5000
> 8< snip
>
>
>
> Basically, all our backends except host_about and host_error go through
> SSL. host_error is forced to HTTP, host_about is kept at whatever the
> client requests.
>
>
>
>
>
> On Wed, Jun 25, 2014 at 3:37 PM, Baptiste wrote:
>
>> On Wed, Jun 25, 2014 at 5:47 PM, Claus Strommer
>> wrote:
>> > Hello all,
>> >
>> > For reasons that I'll spare you I'm working on replacing a Pound
>> balancer
>> > with HAProxy 1.5. I am mostly happy with my configuration, except for
>> one
>> > thing:
>> >
>> > All of my backends accept http, except for a Node.js server which
>> accepts
>> > mixed http and https. This server has a login page that explicitly
>> requires
>> > an SSL connection by checking the local socket used for the connection.
>> In
>> > Pound this was done by setting the HTTPS parameter on the backend,
>> however
>> > from my understanding HAProxy requires that I use TCP passthrough to
>> let the
>> > backend handle SSL. I am uncertain as to how I should shape the HAProxy
>> > configuration to achieve this, as I would like the TCP backend to
>> listen on
>> > the same port as on the HTTP backend. My (simplified) config looks
>> thus:
>> >
>> >
>> > 8< snip
>> > frontend httpweb
>> > bind *:80
>> > bind *:443 ssl crt /etc/ssl/private/primal_bundle_2014.pem
>> > mode http
>> > option httplog
>> >
>> > acl host_about hdr_end(host) -i about.site.com
>> > acl host_api hdr_end(host) -i api.site.com
>> >
>> > redirect scheme https if !{ ssl_fc } require_ssl
>> > redirect scheme http if { ssl_fc } require_nossl
>> >
>> > use backend about:3000 if host_about
>> > use backend api:80 if host_api
>> >
>> > backend about:3000
>> > mode http
>> > balance roundrobin
>> > option httplog
>> > #option httpclose
>> > option forwardfor
>> > server about.backend.com about.backend.com:3000 check inter 5000
>> >
>> > backend api:80
>> > mode http
>> > balance roundrobin
>> > option httplog
>> > #option httpclose
>> > option forwardfor
>> > server api.backend.com api.backend.com:80 check inter 5000
>> >
>> > backend about:3001
>> > mode http
>> > balance roundrobin
>> > option httplog
>> > #option httpclose
>> > option forwardfor
>> > server about.backend.com about.backend.com:3001 check inter 5000
>> > 8< snip
>> >
>> > This of course sends the client into a redirect loop (301) if I hit e.g.
>> > https://about.site.com/login , because the connection between HAProxy
>> and
>> > Node is non-SSL, so it redirects me back to that URL expecting the
>> > subsequent connection to be HTTPS. If I add an about:3001 backend
>> (3001 is
>> > Node's SSL port) I of course get a 502 error because HAProxy connects
>> to it
>> > via non-SSL protocol. I also tried to set the backend to tcp mode but
>> that
>> > failed because the frontend is http.
>> >
>> > So my guess is that I need to add a tcp frontend to handle specifically
>> > HTT
Re: Mixed-mode frontend
Whoops!
Just to be safe, here's the whole thing again, with additions
8< snip
frontend httpweb
bind *:80
bind *:443 ssl crt /etc/ssl/private/primal_bundle_2014.pem
mode http
option httplog
acl host_about hdr_end(host) -i about.site.com
acl host_api hdr_end(host) -i api.site.com
acl require_ssl hdr_end(host) -i api.site.com
acl host_error hdr_end(host) -i error.site.com
acl require_nossl hdr_end(host) -i error.site.com
redirect scheme https if !{ ssl_fc } require_ssl
redirect scheme http if { ssl_fc } require_nossl
use backend about:3000 if host_about
use backend api:80 if host_api
use_backend nginx:8080 if host_error
backend about:3000
mode http
balance roundrobin
option httplog
#option httpclose
option forwardfor
server about.backend.com about.backend.com:3000 check inter 5000
backend api:80
mode http
balance roundrobin
option httplog
#option httpclose
option forwardfor
server api.backend.com api.backend.com:80 check inter 5000
backend about:3001
mode http
balance roundrobin
option httplog
#option httpclose
option forwardfor
server about.backend.com about.backend.com:3001 check inter 5000
backend nginx:8080
mode http
balance roundrobin
option httplog
#option httpclose
option forwardfor
server localhost localhost:8080 check inter 5000
8< snip
Basically, all our backends except host_about and host_error go through
SSL. host_error is forced to HTTP, host_about is kept at whatever the
client requests.
On Wed, Jun 25, 2014 at 3:37 PM, Baptiste wrote:
> On Wed, Jun 25, 2014 at 5:47 PM, Claus Strommer
> wrote:
> > Hello all,
> >
> > For reasons that I'll spare you I'm working on replacing a Pound balancer
> > with HAProxy 1.5. I am mostly happy with my configuration, except for
> one
> > thing:
> >
> > All of my backends accept http, except for a Node.js server which accepts
> > mixed http and https. This server has a login page that explicitly
> requires
> > an SSL connection by checking the local socket used for the connection.
> In
> > Pound this was done by setting the HTTPS parameter on the backend,
> however
> > from my understanding HAProxy requires that I use TCP passthrough to let
> the
> > backend handle SSL. I am uncertain as to how I should shape the HAProxy
> > configuration to achieve this, as I would like the TCP backend to listen
> on
> > the same port as on the HTTP backend. My (simplified) config looks thus:
> >
> >
> > 8< snip
> > frontend httpweb
> > bind *:80
> > bind *:443 ssl crt /etc/ssl/private/primal_bundle_2014.pem
> > mode http
> > option httplog
> >
> > acl host_about hdr_end(host) -i about.site.com
> > acl host_api hdr_end(host) -i api.site.com
> >
> > redirect scheme https if !{ ssl_fc } require_ssl
> > redirect scheme http if { ssl_fc } require_nossl
> >
> > use backend about:3000 if host_about
> > use backend api:80 if host_api
> >
> > backend about:3000
> > mode http
> > balance roundrobin
> > option httplog
> > #option httpclose
> > option forwardfor
> > server about.backend.com about.backend.com:3000 check inter 5000
> >
> > backend api:80
> > mode http
> > balance roundrobin
> > option httplog
> > #option httpclose
> > option forwardfor
> > server api.backend.com api.backend.com:80 check inter 5000
> >
> > backend about:3001
> > mode http
> > balance roundrobin
> > option httplog
> > #option httpclose
> > option forwardfor
> > server about.backend.com about.backend.com:3001 check inter 5000
> > 8< snip
> >
> > This of course sends the client into a redirect loop (301) if I hit e.g.
> > https://about.site.com/login , because the connection between HAProxy
> and
> > Node is non-SSL, so it redirects me back to that URL expecting the
> > subsequent connection to be HTTPS. If I add an about:3001 backend (3001
> is
> > Node's SSL port) I of course get a 502 error because HAProxy connects to
> it
> > via non-SSL protocol. I also tried to set the backend to tcp mode but
> that
> > failed because the frontend is http.
> >
> > So my guess is that I need to add a tcp frontend to handle specifically
> > HTTPS connections for about.site.com. How would I go about doing that?
> Can
> > I have both a TCP and HTTP frontend bind to the same port? How would I
> > shape the ACLs to direct https://about.site.com to the TCP frontend, and
> > everything else to the HTTP frontend?
> >
> >
> >
> > --
> > Claus Strommer, Dev/Ops Engineering Specialist
>
>
> Hi Claus,
>
> first, I don't understand your configuration.
> You may have cut some part of it, but you cut too much :)
> We need to know the content of require_ssl and require_nossl.
> Also, the backend 3001 is not used.
>
> Maybe th
Re: Mixed-mode frontend
On Wed, Jun 25, 2014 at 5:47 PM, Claus Strommer
wrote:
> Hello all,
>
> For reasons that I'll spare you I'm working on replacing a Pound balancer
> with HAProxy 1.5. I am mostly happy with my configuration, except for one
> thing:
>
> All of my backends accept http, except for a Node.js server which accepts
> mixed http and https. This server has a login page that explicitly requires
> an SSL connection by checking the local socket used for the connection. In
> Pound this was done by setting the HTTPS parameter on the backend, however
> from my understanding HAProxy requires that I use TCP passthrough to let the
> backend handle SSL. I am uncertain as to how I should shape the HAProxy
> configuration to achieve this, as I would like the TCP backend to listen on
> the same port as on the HTTP backend. My (simplified) config looks thus:
>
>
> 8< snip
> frontend httpweb
> bind *:80
> bind *:443 ssl crt /etc/ssl/private/primal_bundle_2014.pem
> mode http
> option httplog
>
> acl host_about hdr_end(host) -i about.site.com
> acl host_api hdr_end(host) -i api.site.com
>
> redirect scheme https if !{ ssl_fc } require_ssl
> redirect scheme http if { ssl_fc } require_nossl
>
> use backend about:3000 if host_about
> use backend api:80 if host_api
>
> backend about:3000
> mode http
> balance roundrobin
> option httplog
> #option httpclose
> option forwardfor
> server about.backend.com about.backend.com:3000 check inter 5000
>
> backend api:80
> mode http
> balance roundrobin
> option httplog
> #option httpclose
> option forwardfor
> server api.backend.com api.backend.com:80 check inter 5000
>
> backend about:3001
> mode http
> balance roundrobin
> option httplog
> #option httpclose
> option forwardfor
> server about.backend.com about.backend.com:3001 check inter 5000
> 8< snip
>
> This of course sends the client into a redirect loop (301) if I hit e.g.
> https://about.site.com/login , because the connection between HAProxy and
> Node is non-SSL, so it redirects me back to that URL expecting the
> subsequent connection to be HTTPS. If I add an about:3001 backend (3001 is
> Node's SSL port) I of course get a 502 error because HAProxy connects to it
> via non-SSL protocol. I also tried to set the backend to tcp mode but that
> failed because the frontend is http.
>
> So my guess is that I need to add a tcp frontend to handle specifically
> HTTPS connections for about.site.com. How would I go about doing that? Can
> I have both a TCP and HTTP frontend bind to the same port? How would I
> shape the ACLs to direct https://about.site.com to the TCP frontend, and
> everything else to the HTTP frontend?
>
>
>
> --
> Claus Strommer, Dev/Ops Engineering Specialist
Hi Claus,
first, I don't understand your configuration.
You may have cut some part of it, but you cut too much :)
We need to know the content of require_ssl and require_nossl.
Also, the backend 3001 is not used.
Maybe this could help: if you want to cipher a connection to a server,
then simply add the keyword "ssl" on the server line.
(check also the global parameter ssl-server-verify)
Baptiste
Mixed-mode frontend
Hello all,
For reasons that I'll spare you I'm working on replacing a Pound balancer
with HAProxy 1.5. I am mostly happy with my configuration, except for one
thing:
All of my backends accept http, except for a Node.js server which accepts
mixed http and https. This server has a login page that explicitly requires
an SSL connection by checking the local socket used for the connection. In
Pound this was done by setting the HTTPS parameter on the backend, however
from my understanding HAProxy requires that I use TCP passthrough to let
the backend handle SSL. I am uncertain as to how I should shape the
HAProxy configuration to achieve this, as I would like the TCP backend to
listen on the same port as on the HTTP backend. My (simplified) config
looks thus:
8< snip
frontend httpweb
bind *:80
bind *:443 ssl crt /etc/ssl/private/primal_bundle_2014.pem
mode http
option httplog
acl host_about hdr_end(host) -i about.site.com
acl host_api hdr_end(host) -i api.site.com
redirect scheme https if !{ ssl_fc } require_ssl
redirect scheme http if { ssl_fc } require_nossl
use backend about:3000 if host_about
use backend api:80 if host_api
backend about:3000
mode http
balance roundrobin
option httplog
#option httpclose
option forwardfor
server about.backend.com about.backend.com:3000 check inter 5000
backend api:80
mode http
balance roundrobin
option httplog
#option httpclose
option forwardfor
server api.backend.com api.backend.com:80 check inter 5000
backend about:3001
mode http
balance roundrobin
option httplog
#option httpclose
option forwardfor
server about.backend.com about.backend.com:3001 check inter 5000
8< snip
This of course sends the client into a redirect loop (301) if I hit e.g.
https://about.site.com/login , because the connection between HAProxy and
Node is non-SSL, so it redirects me back to that URL expecting the
subsequent connection to be HTTPS. If I add an about:3001 backend (3001 is
Node's SSL port) I of course get a 502 error because HAProxy connects to it
via non-SSL protocol. I also tried to set the backend to tcp mode but that
failed because the frontend is http.
So my guess is that I need to add a tcp frontend to handle specifically
HTTPS connections for about.site.com. How would I go about doing that?
Can I have both a TCP and HTTP frontend bind to the same port? How would I
shape the ACLs to direct https://about.site.com to the TCP frontend, and
everything else to the HTTP frontend?
--
Claus Strommer, Dev/Ops Engineering Specialist
VPrivées : Polos GEOGRAPHICAL NORWAY - ROHNER - Promo : Caméra MINOX - COMPEX
Offres exclusives sur les produits du site Allsportshop.fr Version en ligne| Ajouter Allsportshop à votre carnet d'adresses VENTES PRIVÉES TEXTILE CYCLE HIGH TECH FITNESS OUTDOOR GLISSE URBAINE BAGAGERIE VENTES PRIVÉES GEOGRAPHICAL NORWAY: ALLSPORTSHOP.fr vous présente les polos de la marque GEOGRAPHICAL NORWAY à -50%. ROHNER : Le spécialiste de la chaussette de sport vous propose sa gamme de compression ainsi que sa ligne de sous-vêtements pour Homme : -50% sur ALLSPORTSHOP.fr CEINTURES SILICONE : Avec ces ceintures et leurs boucles interchangeables, combinez les couleurs à l'infini. -50% + 1 boucle offerte. KYER GEOGRAPHICAL NORWAY Modèle existant en 5 coloris 10 autres produits de la gamme sont disponibles 49,90€ 24,95€ ACCÉDER À LA VENTE KEDDY GEOGRAPHICAL NORWAY Modèle existant en 4 coloris 10 autres produits de la gamme sont disponibles 59,90€ 29,50€ ACCÉDER À LA VENTE Chaussettes Compression ROHNER 4 modèles disponibles Golf, R-Power, Tube, EveryDay -50% ACCÉDER À LA VENTE Sous-vêtements Homme ROHNER 8 modèles : Polos, T-shirts, débardeurs, boxers, calleçons ... -50% ACCÉDER À LA VENTE Boucle supplémentaire offerte Ceintures Silicone Commandez une ceinture et choisissez la couleur de votre boucle 29,90€ 14,95€ ACCÉDER À LA VENTE PROMO MINOX : La Caméra Action Cam MINOX ACX 100 HD sera le compagnon idéal pour filmer vos activités de loisirs, la pratique de sports extrêmes ou tout simplement votre quotidien. COMPEX : 8 stimulateurs musculaires électriques sont en soldes à -20%. Pour l'achat d'un produit COMPEX, recevez 6 électrodes supplémentaires gratuites. Action Cam ACX 100HD MINOX 1080p en Full HD 2H d'enregistrement non-stop 215,00€ 150,50€ VOIR LE PRODUIT Stimulateurs Musculaires COMPEX 8 produits de la marque en Soldes 6 électrodes supplémentaires offertes -20% VOIR LES PRODUITS NOUVEAU LaPLAYA : ALLSPORTSHOP.fr vous fait découvrir les nouveaux produits LaPLAYA : - Une gamme complète de sacs IMPERMÉABLES pour vos différents déplacements. - Différents modèles de gourdes isothermes, plastiques ou alu qui vous permettent d'emporter vos boissons favorites chaudes ou froides. Gamme Bagagerie LaPLAYA Sac Jumbo, sac à dos, Square Bag, Sac Messenger À partir de 59,95€ VOIR LE PRODUIT Gourdes LaPLAYA Contenances : 1L 0,9L 0,7L 0,6L 0,5L À partir de 6,99€ VOIR LES PRODUITS ENTREPRISE FRANÇAISE SATISFAIT OU REMBOURSÉ PAIEMENT 100% SÉCURISÉ PAIEMENT PAYPAL PAIEMENT 3DSECURE ALLSPORTSHOP SUR FACEBOOK Consulter la version en ligne Pour être certain de bien recevoir nos messages, ajoutez Allsportshop à votre carnet d'adresses. Se désinscrire de cette newsletter
Typo in stats interface
Hi There is a very small typo in the statistics interface: a "set" in lowercase where allothers are uppercase "Set" I am sorry, but I do not know how to properly document the change I made... hope that is helps. .marcoc diff --git a/src/dumpstats.c b/src/dumpstats.c index 5365042..c8bac08 100644 --- a/src/dumpstats.c +++ b/src/dumpstats.c @@ -3710,7 +3710,7 @@ static void stats_dump_html_px_end(struct stream_interface *si, struct proxy *px "" "Set state to READY" "Set state to DRAIN" - "Set state to MAINT" + "set state to MAINT" "Health: disable checks" "Health: enable checks" "Health: force UP"
Re: backend server marked up after restart/reload on 1.4.25
Hi Corey, On Wed, Jun 25, 2014 at 01:26:25AM -0700, Corey Osman wrote: > HI, > > I have noticed that when I restart/reload haproxy, haproxymarks the servers > in the backends as up without ever checking them. > > So traffic is being sent to the backend server even while the backend server > is actually down. This occurs until the first health check fails on the > server and haproxy marks the server as down. > > I realize that changing the interval to something lower would mask this > problem but I don?t want to flood my server with health checks. > > I would expect haproxy to treat the server as down until the health checks > passes. (guilty until proven innocence). Again this is only upon > restart/reload. > > I am wondering if this is an bug in haproxy or a configuration issue on my > part. Is there something missing from my config? Neither, it's the expected behaviour. Trying to send traffic to a server for 1 second or so on startup is *much* less a trouble than sending traffic to no server at all and disrupting the whole service. There has been a discussion recently about adding the ability to decide whether to start up or down for a server. I guess that the recent activities have masked a bit this low-priority work. Willy
backend server marked up after restart/reload on 1.4.25
HI, I have noticed that when I restart/reload haproxy, haproxymarks the servers in the backends as up without ever checking them. So traffic is being sent to the backend server even while the backend server is actually down. This occurs until the first health check fails on the server and haproxy marks the server as down. I realize that changing the interval to something lower would mask this problem but I don’t want to flood my server with health checks. I would expect haproxy to treat the server as down until the health checks passes. (guilty until proven innocence). Again this is only upon restart/reload. I am wondering if this is an bug in haproxy or a configuration issue on my part. Is there something missing from my config? My backend is below backend SiteMonitor mode http option httpchk GET /healthcheck http-check expect string all_good server main-server 192.168.1.3:5000 rise 1 fall 1 maxconn 2 check inter 10s thanks, Corey
Re: invalidate errorfile cache to trick upstream load balancer
Hi Corey, On Wed, Jun 25, 2014 at 12:05:59AM -0700, Corey Osman wrote: > Hi, > > I am using a custom 200 response file so that my upstream load balancer can > determine if my haproxy instance is operating correctly. > >errorfile 200 /home/haproxy/responses/200_resp.http > > Additionally I am using the monitor-uri /healthcheck. > > So when my upstream load balancer calls haproxyhost:port/healthcheck haproxy > will return the contents of the 200_resp.http file. > > This all works fine, however if I change the contents of the 200 response > file when haproxy is running I have noticed that haproxy is actually caching > this file. > > The caching part is fine, however in order for haproxy to see the updated > response file I must restart/reload haproxy so it picks up the new contents. > > You might be asking why am I changing this file? Well basically if I need to > perform rolling restarts on my haproxy instances I need a method of signaling > the upstream load balancer health check > to remove the haproxy instance from the available pool. So if I change the > contents of the 200 response I can basically automatically remove the haproxy > instance from the pool and traffic will no longer flow to > the haproxy instance. However, because haproxy caches this file I need to > restart/reload haproxy. I would like to not have to perform this restart > though. > > Is there any way to signal haproxy to invalidate the error file cache and > reread the errorfiles without restarting? No, but you need to be aware that haproxy is not a file server, but a load balancer. It reads *all* of its configuration upon startup, is supposed to be chrooted and to drop its privileges, then it does not have any more access to the file system. > Can this be done through the stats socket? > > Is anybody else doing this and have a better method? Normally you're supposed to do this using "monitor-fail if ...". It will replace the 200 with the 500 based on a condition that you're free to determine. Hoping this helps, Willy
invalidate errorfile cache to trick upstream load balancer
Hi, I am using a custom 200 response file so that my upstream load balancer can determine if my haproxy instance is operating correctly. errorfile 200 /home/haproxy/responses/200_resp.http Additionally I am using the monitor-uri /healthcheck. So when my upstream load balancer calls haproxyhost:port/healthcheck haproxy will return the contents of the 200_resp.http file. This all works fine, however if I change the contents of the 200 response file when haproxy is running I have noticed that haproxy is actually caching this file. The caching part is fine, however in order for haproxy to see the updated response file I must restart/reload haproxy so it picks up the new contents. You might be asking why am I changing this file? Well basically if I need to perform rolling restarts on my haproxy instances I need a method of signaling the upstream load balancer health check to remove the haproxy instance from the available pool. So if I change the contents of the 200 response I can basically automatically remove the haproxy instance from the pool and traffic will no longer flow to the haproxy instance. However, because haproxy caches this file I need to restart/reload haproxy. I would like to not have to perform this restart though. Is there any way to signal haproxy to invalidate the error file cache and reread the errorfiles without restarting? Can this be done through the stats socket? Is anybody else doing this and have a better method? How do I make a feature request if this functionality is not available? thanks, Corey Osman
