Re: How to turn on/off maintenance page in a smart way?
Hi, You can either use the disable-on-404 health checking option or using HAProxy socket to disable servers temporarly (I mean temporarly because the UNIX socket applies changes in running HAProxy process, not in its startup configuration file). You could then have a few simple acl matching the number of available servers in a farm (this also may mean you must have a backend by application). use_backend maintenance_page if is_app1 nb_srv(bk_app1) eq 0 use_backend bk_app1if is_app1 now, just create a bash script to loop through the HAProxy unix stat socket to disable the servers: echo "disable server bk_app1/srv1" | socat /var/run/haproxy.socket - Baptiste On Tue, Apr 2, 2013 at 8:42 AM, Unai Rodriguez wrote: > Dear List, > > We have a number of applications behind HAProxy. Sometimes we need to put > one of the applications in maintenance mode (i.e. display a "This page is > under maintenance banner"). We achieve that with the following rules: > > acl is_app1 hdr(host) app1.example.com > acl is_app2 hdr(host) app2.example.com > acl is_app3 hdr(host) app3.example.com > acl is_app4 hdr(host) app4.example.com > acl is_app5 hdr(host) app5.example.com > acl is_app6 hdr(host) app6.example.com > acl is_app7 hdr(host) app7.example.com > acl is_app8 hdr(host) app8.example.com > acl is_app9 hdr(host) app9.example.com > acl is_app0 hdr(host) app0.example.com > > use_backend maintenance_page if is_app1 > #use_backend maintenance_page if is_app2 > #use_backend maintenance_page if is_app3 > #use_backend maintenance_page if is_app4 > #use_backend maintenance_page if is_app5 > #use_backend maintenance_page if is_app6 > #use_backend maintenance_page if is_app7 > #use_backend maintenance_page if is_app8 > #use_backend maintenance_page if is_app9 > #use_backend maintenance_page if is_app0 > > Currently what we do is comment/uncomment lines manually and reload > HAProxy when wanting to put app1, app2, app3... under maintenance. > > This is somewhat error prone and we are looking for a way of doing this in > a more sophisticated manner. Ideally someone should be able to login on a > simple web page, click a button and enable/disable applications as needed. > > We used to do that in the past by having several HAProxy configurations > but now this would mean to have 100 config files to cover all different > posibilities. > > What ACLs can be used so that HAProxy does NOT need to be reloaded? We > haven't been able to find matching criteria that depends on the existance > of a file locally for example (or some other environment variable). I guess > we could serve HTTP 200 or HTTP 503 for example (to put appX on/off) but is > there a more elegant/better way? > > Thank you so much > > -- > unai > >
How to turn on/off maintenance page in a smart way?
Dear List, We have a number of applications behind HAProxy. Sometimes we need to put one of the applications in maintenance mode (i.e. display a "This page is under maintenance banner"). We achieve that with the following rules: acl is_app1 hdr(host) app1.example.com acl is_app2 hdr(host) app2.example.com acl is_app3 hdr(host) app3.example.com acl is_app4 hdr(host) app4.example.com acl is_app5 hdr(host) app5.example.com acl is_app6 hdr(host) app6.example.com acl is_app7 hdr(host) app7.example.com acl is_app8 hdr(host) app8.example.com acl is_app9 hdr(host) app9.example.com acl is_app0 hdr(host) app0.example.com use_backend maintenance_page if is_app1 #use_backend maintenance_page if is_app2 #use_backend maintenance_page if is_app3 #use_backend maintenance_page if is_app4 #use_backend maintenance_page if is_app5 #use_backend maintenance_page if is_app6 #use_backend maintenance_page if is_app7 #use_backend maintenance_page if is_app8 #use_backend maintenance_page if is_app9 #use_backend maintenance_page if is_app0 Currently what we do is comment/uncomment lines manually and reload HAProxy when wanting to put app1, app2, app3... under maintenance. This is somewhat error prone and we are looking for a way of doing this in a more sophisticated manner. Ideally someone should be able to login on a simple web page, click a button and enable/disable applications as needed. We used to do that in the past by having several HAProxy configurations but now this would mean to have 100 config files to cover all different posibilities. What ACLs can be used so that HAProxy does NOT need to be reloaded? We haven't been able to find matching criteria that depends on the existance of a file locally for example (or some other environment variable). I guess we could serve HTTP 200 or HTTP 503 for example (to put appX on/off) but is there a more elegant/better way? Thank you so much -- unai
Re: possible crashes on linux with recent glibc
Hi Brian, On Mon, Apr 01, 2013 at 07:11:25PM -0700, Bryan Talbot wrote: > haproxy built with macports on OSX seems to only have support for select() > and not poll(). I don't have any suggestions but is this environment > impacted by your proposed changes? It's a Makefile issue, OSX supports select(), poll() and kqueue(). And BTW, OSX is one of those causing issues with select() and fd >= 1024 according to the man page. In fact all operating systems where haproxy may be built support poll(). > Not running haproxy on osx for anything other than localhost development > mode of course, but keeping it working on osx would be great. You're right, I'm going to fix the makefile right now. > $> /opt/local/sbin/haproxy -vv > HA-Proxy version 1.4.22 2012/08/09 > Copyright 2000-2012 Willy Tarreau > > Build options : > TARGET = osx ^^^ The issue is here above. The "osx" target is not defined so no option is taken. So first I'll define such a target because it makes sense to have it, and second, I'll enable POLL by default when the target is unknown. And this way you'll get a better development platform :-) Thanks, Willy
Re: possible crashes on linux with recent glibc
On Fri, Mar 29, 2013 at 11:01 AM, Willy Tarreau wrote: > Hi, > > > For the medium term, I'm going to prepare the following changes : > > - make poll() rely solely on bit fields without using FD_* macros > - add a start up warning when select() is used with a maxconn leading > to more than FD_SETSIZE fds, followed by a runtime test to make it > crash in glibc while parsing the config if needed instead of reserving > a friday evening surprize for you. > - enable poll() by default in the generic target, as it's supported on > all platforms where haproxy is known to build > haproxy built with macports on OSX seems to only have support for select() and not poll(). I don't have any suggestions but is this environment impacted by your proposed changes? Not running haproxy on osx for anything other than localhost development mode of course, but keeping it working on osx would be great. $> /opt/local/sbin/haproxy -vv HA-Proxy version 1.4.22 2012/08/09 Copyright 2000-2012 Willy Tarreau Build options : TARGET = osx CPU = generic CC = /usr/bin/clang -arch x86_64 CFLAGS = -O2 -g -fno-strict-aliasing OPTIONS = USE_LIBCRYPT=1 USE_REGPARM=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Available polling systems : select : pref=150, test result OK Total: 1 (1 usable), will use select.
Re: [PATCH] Use PCRE JIT in acl
Hi, On Wed, Feb 20, 2013 at 03:26:59AM +0900, Hiroaki Nakamura wrote: > Hi, > > Thank you for your review. > Sorry for being late, now I made a new patch. > > As you suggested, I added struct jit_regex. I also add typedef to > avoid #ifdef's scatter here and there. I think the code becomes cleaner. > > Could you review it? I didn't notice your second review request. This one is much better. Given that I'm about to issue dev18 and I'm a bit embarrassed for having let your work unreviewed for 1.5 months, I have performed a few very minor changes and merged it : - renamed the typedef "regex" instead of "regexp" since it's how all the other types are named, including the file where it's defined - moved the exec and free wrapper to static inline so that we don't call an intermediate function - adjusted the makefile to support building with just USE_PCRE_JIT=1 That's great work overall, let's wait for success stories. Thanks, Willy
Re: [PATCH v2] BUG/MEDIUM: systemd-wrapper: don't leak zombie processes
On 1 April 2013 23:49, Willy Tarreau wrote: > Great. I'm planning a dev18 release for tomorrow afternoon, tell me > if you want me to wait a bit more. > > Thanks, > Willy > It will be ready before the afternoon so that you can get it in dev18! Thanks
Re: [PATCH v2] BUG/MEDIUM: systemd-wrapper: don't leak zombie processes
On Mon, Apr 01, 2013 at 11:38:00PM +0200, Marc-Antoine Perennou wrote: > Hi, > > After checking out the man page of waitpid, wait would indeed be sufficient > here. > I didn't actually know about waitpid(-1) > > I'll resubmit an updated patch tomorrow! Great. I'm planning a dev18 release for tomorrow afternoon, tell me if you want me to wait a bit more. Thanks, Willy
Re: [PATCH] DOCS: Add explanation of intermediate certs to crt paramater
Hi Alex, On Sat, Mar 02, 2013 at 04:04:50PM +, Alex Davies wrote: > This change makes the "crt" block of the documentation easier to use > for those not clear on what needs to go in what file, specifically for > those using CAs that require intermediate certificates. Applied, thank you for taking care of the doc ! Willy
Re: [PATCH v2] BUG/MEDIUM: systemd-wrapper: don't leak zombie processes
Hi, After checking out the man page of waitpid, wait would indeed be sufficient here. I didn't actually know about waitpid(-1) I'll resubmit an updated patch tomorrow! Thanks On 1 April 2013 23:32, Willy Tarreau wrote: > Hi Marc-Antoine, > > On Thu, Mar 14, 2013 at 02:50:56PM +0100, Marc-Antoine Perennou wrote: > > Formerly, if A was replaced by B, and then B by C before > > A finished exiting, we didn't wait for B to finish so it > > ended up as a zombie process. > > Fix this by queuing all process we spawn for waitpid. > > I'm a bit puzzled, why is it necessary to keep a queue of all spawned > processes ? The system already has one, so we should simply do a wait() > or waitpid(-1). > > Am I missing something ? > > Willy > >
Re: [PATCH v2] BUG/MEDIUM: systemd-wrapper: don't leak zombie processes
Hi Marc-Antoine, On Thu, Mar 14, 2013 at 02:50:56PM +0100, Marc-Antoine Perennou wrote: > Formerly, if A was replaced by B, and then B by C before > A finished exiting, we didn't wait for B to finish so it > ended up as a zombie process. > Fix this by queuing all process we spawn for waitpid. I'm a bit puzzled, why is it necessary to keep a queue of all spawned processes ? The system already has one, so we should simply do a wait() or waitpid(-1). Am I missing something ? Willy
Re: [PATCH 0/3] Add http-check agent-hdr option
Hi Simon, Sorry for the long delay and thanks for waiting. I've just reviewed your two patch series (16 total). They're pretty good in my opinion. I'm seeing a few points we'll probably have to adjust : - normally, health checks reserve file descriptors (one per checked server), here we'll have to count up to two fds when the two checks are enabled. I don't remember where this is done, maybe in haproxy.c. - I think that we'll soon have to support an agent-addr parameter, which means that ->addr will have to move from check_common to struct check. The reason for the last point is that I'm pretty sure that a number of uses of the agent will involve checking a component to get reliability information about the server itself. It might simply be because the server runs on multiple addresses, or in transparent mode. But it might also be because a monitoring station is checked to retrieve the server status. Also what I like with your approach with the "struct check" is that it could make it easier to combine tests later. Many people ask how it is possible to check two ports at a time and AND them. Till now it was not possible but now it starts to be possible. We already have a massive number of patches pending for dev18, so I think I'll issue dev18 now then open post-dev18 with your patches. Thank you! Willy
Re: haproxy in the sky
Yeah, brilliant, it passed over versailles, 1h after leaving your flat :) Fun to see how far it's going to go! Baptiste On Mon, Apr 1, 2013 at 2:12 PM, david rene comba lareu < shadow.of.sou...@gmail.com> wrote: > Hi, > > very cool ! thanks for sharing it :) > > Regards, > Shadow. > > > 2013/4/1 Willy Tarreau > >> For those interested, here's a little experiment I did over the week-end : >> >>http://haproxy.1wt.eu/hap-in-the-sky.html >> >> Not too hard to reproduce, have fun! >> Willy >> >> >> >
Re: haproxy in the sky
Hi, very cool ! thanks for sharing it :) Regards, Shadow. 2013/4/1 Willy Tarreau > For those interested, here's a little experiment I did over the week-end : > >http://haproxy.1wt.eu/hap-in-the-sky.html > > Not too hard to reproduce, have fun! > Willy > > >
haproxy in the sky
For those interested, here's a little experiment I did over the week-end : http://haproxy.1wt.eu/hap-in-the-sky.html Not too hard to reproduce, have fun! Willy
