Re: substring matching backend names...

[Pavlos Parissis]

On 10/07/2015 10:32 μμ, Phillip Decker wrote:
> Hello again,
>  
> I was migrating a setup from the older style acl-based host to backend 
> mapping, to the newer
> map-based approach, e.g.
>  
> use_backend  %[req.hdr(host),lower,map_beg(mapping.conf,default)]
>  
> and that works fine.  But now I'm tempted to simply name the backends after 
> each servername,
> (eg. 'mail' from mail.google.com , or 'maps' from 
> maps.google.com
> ). 
>  
> Which in my imagination would look something like:
>  
> use_backend %[req.hdr_beg(host),lower]
>  
> But is there a way to substring or regex off the front of the host string, 
> and pass that to the
> use_backend call?
>  
> In other words, continuing the google.com  example, if 
> people are hitting
> the server with "host: mail.google.com ", and 
> maps.google.com
> , and just for completeness, notes.books.google.com
> , I'd like to have backends:
>  
> backend mail
>mode http
>foo
>
>  
> backend maps
>mode http
>bar
>...
>  
>  backend notes.books
>mode http
>baz
>..
>  
> Is there a way to accomplish this without building them into a mapped file in 
> 1.5.x? 
>  
> (1.6 solutions are okay too, but won't be able to move to that until it's in 
> stable.)

1.6 is *stable*. It has been running fine in several setups I manage since 
dev6:-)
But, I guess you meant in *stable* repo of X distribution, right?

Cheers,
Pavlos






signature.asc
Description: OpenPGP digital signature

Re: HAProxy description server status

[Cyril Bonté]

Hi Martin,

Le 25/07/2016 à 15:08, Martin Šindler a écrit :

Hi,
I hope, that I'm writing the correct person, if not please forward this
question to correct one.

We are try to implement HAProxy and we are performing some tests, one of
our requirement is automatic management of HAProxy during server
maintenance, this need reading status of servers and put nods to
appropriate state.

I'm faced to problem regarding some missing information in documentation
(maybe this information is present but i can't find it).

_Problem:_
when i prompt command: *show servers state Test-cluster*

It returns me output which can be reformated to someting like:

be_id  : 5
be_name: Test-cluster
srv_id : 2
srv_name   : clstrnod2
srv_addr   : 192.168.10.6
srv_op_state   : *2*
srv_admin_state: 0
srv_uweight: 8
srv_iweight: 10
srv_time_since_last_change : 264872
srv_check_status   : 9
srv_check_result   : 3
srv_check_health   : 7
srv_check_state: 6
srv_agent_state: 22
bk_f_forced_id : 0
srv_f_forced_id: 0

I found in documentation that for example :

srv_op_state:Server operational state (UP/DOWN/...).

But there is no clue to realize what means INTEGER value 2. I have this
problem for all other status values as well. Could you please help me to
find documentation where is written what INTEGER values represents?


If Willy is OK with the patch, here is a documentation update to include 
the different values found in the source code.



--
Cyril Bonté
>From 093584f88e01c585e7a7cf71e771f6f0a69100ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cyril=20Bont=C3=A9?= 
Date: Mon, 25 Jul 2016 22:18:27 +0200
Subject: [PATCH] DOC: stats: provide state details for show servers state

Add the state values to the documentation instead of adding a reference to the
source code.
---
 doc/management.txt | 60 +-
 1 file changed, 55 insertions(+), 5 deletions(-)

diff --git a/doc/management.txt b/doc/management.txt
index caf7eb0..74c5a41 100644
--- a/doc/management.txt
+++ b/doc/management.txt
@@ -1848,20 +1848,70 @@ show servers state []
  srv_name:Server label.
  srv_addr:Server IP address.
  srv_op_state:Server operational state (UP/DOWN/...).
-  In source code: SRV_ST_*.
+0 = SRV_ST_STOPPED
+  The server is down.
+1 = SRV_ST_STARTING
+  The server is warming up (up but
+  throttled).
+2 = SRV_ST_RUNNING
+  The server is fully up.
+3 = SRV_ST_STOPPING
+  The server is up but soft-stopping
+  (eg: 404).
  srv_admin_state: Server administrative state (MAINT/DRAIN/...).
-  In source code: SRV_ADMF_*.
+  The state is actually a mask of values :
+0x01 = SRV_ADMF_FMAINT
+  The server was explicitly forced into
+  maintenance.
+0x02 = SRV_ADMF_IMAINT
+  The server has inherited the maintenance
+  status from a tracked server.
+0x04 = SRV_ADMF_CMAINT
+  The server is in maintenance because of
+  the configuration.
+0x08 = SRV_ADMF_FDRAIN
+  The server was explicitly forced into
+  drain state.
+0x10 = SRV_ADMF_IDRAIN
+  The server has inherited the drain status
+  from a tracked server.
  srv_uweight: User visible server's weight.
  srv_iweight: Server's initial weight.
  srv_time_since_last_change:  Time since last operational change.
  srv_check_status:Last health check status.
  srv_check_result:Last check result (FAILED/PASSED/...).
-  In source code: CHK_RES_*.
+0 = CHK_RES_UNKNOWN
+  Initialized to this by default.
+1 = CHK_RES_NEUTRAL
+  

[SPAM] іΝ420171638

[OSiApple]

 




	
		
			
			

			
			
			Apple Management

			Hi haproxy@formilux.org,
			

			
			Your account may become inactive.

			Please Continue and review your data. 

			 

			Continue and Login

			 

			 
			

			
			

	
		
		Thank you,

		Apple Management Team!
		
		OS X El Capitan brings lots of useful enhancements to your Mac. New ways to manage multiple windows and spaces. An even more powerful Spotlight for searching your Mac and beyond. Refinements to essential apps like Photos, Safari, Mail and Maps. An all-new Notes app for gathering your thoughts, photos, maps, web links and more. And faster performance across the board, from gaming to launching apps to accessing mail.
		
	

			
			
			
		
	



© 2016 Apple Inc. 1620 Amphitheatre Parkway, Mountain View, CA 944043

Attn: purchasing-terminal blocks and connectors

[tuqff]

Dear purchase manager,

I have heard that you have a need for the original electronic components,So 
contact you
Glad to learn you’re on the market of electronic components . We are a leading 
manufacturer of terminal blocks and connectors , with good quality and 
competitive price .Please contact us if any interesting.Best regards,David 
Cixi Wan Hai Electronics Co., Ltd.(China) 
Web :www.cnwanhai.com

Re: 100% CPU by epoll loop, while waiting for connection timeout

[Willy Tarreau]

Hi Tobias,

On Mon, Jul 25, 2016 at 04:24:51PM +0200, Tobias Vau wrote:
> > The detailed session state would be needed. You can have it by either
> > requesting "show sess " ex "show sess 0x7fd3aaa28040" below, or
> > by issuing "show sess all" which will dump them all (much more useful
> > as it allows us to validate a theory across other sessions).
> 
> I expected, that you'll ask for these, so I also saved them at that time and
> will forward them in private.

Thanks!

> From what I saw on multiple occurences of these conditions, that it seemded to
> be the case, that there were always mobile internet connections involved in
> this - but this could of course just be unrelated coincidence.

OK so as a guess we should indeed expect the client to time out first to
help reproduce this case.

> > The problem I've been facing was how to reproduce the condition. If you
> > manage to reproduce it within a minute or so at 10 cps, it would be very
> > useful to also take a tcpdump capture in parallel of the traffic between
> > the client and haproxy and the traffic between haproxy and the server.
> > That will help understand what traffic sequence triggers the issue and
> > possibly what headers if any is involved. It also allows to eliminate
> > some theories based on the configuration.
> 
> The test system I had, is already put into production (without the problematic
> settings activated). As I already experienced the problems with only a less
> important sub-domain routed over that haproxy-instance, I'll try to setup
> a second clone of the instance. I just need some spare hours, to re-route that
> specific sub-domain over the new clone again and log as much as possible.

Oh I understand the problems, don't worry!

> As I do not know in advance, which client would cause the fulty conditions,
> would two separate multi-minute tcpdumps of
> 
>   1) all client traffic to the loadbalancer IP
>   2) all haproxy traffic to the backend
> 
> still be useful to you? They could then still at least be filtered for one
> client IP that owns such a faulty session.

Definitely! That would be great!

> > You need to be fully aware that this will disclose a lot of private
> > information so you definitely don't want to post this here. You may want
> > to follow up with an anonymized example of a show sess if you want, and/or
> > with any possibly relevant new information.
> 
> As this single subdomain is only used for delivering some banner images, the
> privacy concerns for giving out the dumps would also be lessened a lot. I'd of
> course still send these dumps in private.

Yes that's preferable. As much as I would like to dig through this type
of stuff publicly, we're always confronted to the same issue of disclosing
real traffic and that's not nice.

Thanks!
Willy

Re: 100% CPU by epoll loop, while waiting for connection timeout

[Tobias Vau]

Hi Willy,

2016-07-20 21:08 GMT+02:00 Willy Tarreau :
> Hi Tobias,
>
> On Thu, Jul 14, 2016 at 04:52:29PM +0200, Tobias Vau wrote:
>> Hi,
>>
>> a small follow up to an older thread from November 2015, where massive
>> numbers of epoll_wait calls lead to 100% CPU consumption.
>>
>> My installation showed the same pattern. As it's also easily
>> reproducible for me with very moderate client traffic (1-10 conns/s),
>> you might maybe be interested in more debug info.
>> [...]
>> As I can very easily reproduce the behaviour with the current config
>> and a very moderate traffic pattern (1-5 conns / s), just let me know,
>> if you'd like to see some other debug info, than what's provided below.
>
> That's very useful.
>
> The detailed session state would be needed. You can have it by either
> requesting "show sess " ex "show sess 0x7fd3aaa28040" below, or
> by issuing "show sess all" which will dump them all (much more useful
> as it allows us to validate a theory across other sessions).

I expected, that you'll ask for these, so I also saved them at that time and
will forward them in private.

>From what I saw on multiple occurences of these conditions, that it seemded to
be the case, that there were always mobile internet connections involved in
this - but this could of course just be unrelated coincidence.

> The problem I've been facing was how to reproduce the condition. If you
> manage to reproduce it within a minute or so at 10 cps, it would be very
> useful to also take a tcpdump capture in parallel of the traffic between
> the client and haproxy and the traffic between haproxy and the server.
> That will help understand what traffic sequence triggers the issue and
> possibly what headers if any is involved. It also allows to eliminate
> some theories based on the configuration.

The test system I had, is already put into production (without the problematic
settings activated). As I already experienced the problems with only a less
important sub-domain routed over that haproxy-instance, I'll try to setup
a second clone of the instance. I just need some spare hours, to re-route that
specific sub-domain over the new clone again and log as much as possible.

As I do not know in advance, which client would cause the fulty conditions,
would two separate multi-minute tcpdumps of

  1) all client traffic to the loadbalancer IP
  2) all haproxy traffic to the backend

still be useful to you? They could then still at least be filtered for one
client IP that owns such a faulty session.

> You need to be fully aware that this will disclose a lot of private
> information so you definitely don't want to post this here. You may want
> to follow up with an anonymized example of a show sess if you want, and/or
> with any possibly relevant new information.

As this single subdomain is only used for delivering some banner images, the
privacy concerns for giving out the dumps would also be lessened a lot. I'd of
course still send these dumps in private.

Kind regards
Tobias

HAProxy description server status

[Martin Šindler]

Hi,
I hope, that I'm writing the correct person, if not please forward this
question to correct one.

We are try to implement HAProxy and we are performing some tests, one of
our requirement is automatic management of HAProxy during server
maintenance, this need reading status of servers and put nods to
appropriate state.

I'm faced to problem regarding some missing information in documentation
(maybe this information is present but i can't find it).

*Problem:*
when i prompt command: *show servers state Test-cluster*

It returns me output which can be reformated to someting like:

be_id  : 5
be_name: Test-cluster
srv_id : 2
srv_name   : clstrnod2
srv_addr   : 192.168.10.6
srv_op_state   : *2*
srv_admin_state: 0
srv_uweight: 8
srv_iweight: 10
srv_time_since_last_change : 264872
srv_check_status   : 9
srv_check_result   : 3
srv_check_health   : 7
srv_check_state: 6
srv_agent_state: 22
bk_f_forced_id : 0
srv_f_forced_id: 0

I found in documentation that for example :

srv_op_state:Server operational state (UP/DOWN/...).

But there is no clue to realize what means INTEGER value 2. I have this
problem for all other status values as well. Could you please help me to
find documentation where is written what INTEGER values represents?

Thank you very much

Martin Sindler

Re: Host name resolution in IPv6 only entry in /etc/hosts

[Willy Tarreau]

Hi Nenad,

On Mon, Jul 25, 2016 at 10:30:55AM +0200, Nenad Merdanovic wrote:
> Hello Willy,
> 
> On 7/20/2016 9:28 PM, Willy Tarreau wrote:
> > I vaguely remind such a conversation in the past with reports of
> > getaddrinfo() not returning what was expected. Maybe that's something
> > to consider for a next major version (eg: 1.7). However we could
> > possibly have something intermediary for 1.6 : having the option to
> > force to use GAI and not use it by default. That wouldn't break existing
> > setups and would allow those who need it to use it as-is. We'd basically
> > build with "USE_GHBN_FIRST" in addition to "USE_GETADDRINFO", it would
> > then use only gethostbyname except if the option forces the other one.
> > 
> > Does this sound like a reasonable option ?
> 
> It sounds fine, until I think all the various ways we enable or disable
> this. We have:
> - Build option to build with gai(), preferring it
> - Runtime flag to disable gai(), falling back to ghbn()
> - Configuration option to disable gai(), falling back to ghbn()
> 
> Now we would need to add:
> - Build option to prefer ghbn() when gai() is enabled
> - A configuration option/runtime flag to switch back to gai() in the
> case above
> 
> I am pretty familiar with this part of the code, and it makes my head
> hurt :)
> 
> I'd vote to keep 1.6 as is, and completely break 1.7 by removing the
> build option USE_GETADDRINFO and building with it by default, perhaps
> switching to NO_GETADDRINFO for any platforms that are broken (if such
> exist). We then just keep the runtime flag/config option for people who
> wish to disable it.

We definitely need to have an option to disable it, because getaddrinfo
is broken on *many* platforms. In fact when implementing it I had a hard
time finding a really working one. Not kidding. Things have evolved since,
but legacy systems are still used quite a lot with either no or a broken
implementation (broken in various ways), and several embedded libraries
don't have a working one either or only recently fixed theirs.

Otherwise I'm fine with your proposal (ie make it the default starting
with 1.7 and not touch 1.6).

Regards,
willy

Re: Host name resolution in IPv6 only entry in /etc/hosts

[Nenad Merdanovic]

Hello Willy,

On 7/20/2016 9:28 PM, Willy Tarreau wrote:
> I vaguely remind such a conversation in the past with reports of
> getaddrinfo() not returning what was expected. Maybe that's something
> to consider for a next major version (eg: 1.7). However we could
> possibly have something intermediary for 1.6 : having the option to
> force to use GAI and not use it by default. That wouldn't break existing
> setups and would allow those who need it to use it as-is. We'd basically
> build with "USE_GHBN_FIRST" in addition to "USE_GETADDRINFO", it would
> then use only gethostbyname except if the option forces the other one.
> 
> Does this sound like a reasonable option ?

It sounds fine, until I think all the various ways we enable or disable
this. We have:
- Build option to build with gai(), preferring it
- Runtime flag to disable gai(), falling back to ghbn()
- Configuration option to disable gai(), falling back to ghbn()

Now we would need to add:
- Build option to prefer ghbn() when gai() is enabled
- A configuration option/runtime flag to switch back to gai() in the
case above

I am pretty familiar with this part of the code, and it makes my head
hurt :)

I'd vote to keep 1.6 as is, and completely break 1.7 by removing the
build option USE_GETADDRINFO and building with it by default, perhaps
switching to NO_GETADDRINFO for any platforms that are broken (if such
exist). We then just keep the runtime flag/config option for people who
wish to disable it.

Regards,
Nenad

Re: counters for specific http status code

[Willy Tarreau]

On Mon, Jul 25, 2016 at 05:58:52AM +, Ruoshan Huang wrote:
> hi Willy,    please check this thread again when you are free. thanks

Hi Ruoshan,

yes I've added it to my todo list. Hopefully today.

thanks,
Willy