Re: Meaning of hrsp_2xx in show_stat

[Ashish Jaiswal]

Hi Jonathan,

No I don't think there is any issue when saving these stats, So I think 
this is a bug itself which needs to be fixed ?


# while true; do echo 'show stat' | socat - 
UNIX-CLIENT:/var/run/haproxy.sock | grep BACKEND | cut -d , -f 2,41; 
sleep 1; done

BACKEND,15325469
BACKEND,15325511
BACKEND,14387610
BACKEND,14387660
BACKEND,13854344
BACKEND,14387745
BACKEND,13854440
BACKEND,15045037
BACKEND,15045086
BACKEND,15325845
BACKEND,15325895
BACKEND,14388003

On Friday 14 June 2013 11:28:15 PM IST, Jonathan Matthews wrote:

On 14 June 2013 10:10, Ashish Jaiswal  wrote:

HI Jonathan,

You mean to say that the hrsp_2xx will always increment.  But it doesn't
seems to be as the value are always floating.
My major concern is how will one manage to see that how many client are
getting and 3xx/2xx code when they are getting served.
The "show stat" can be looked up as many time we want. Is there any way
where we can be sure that the show stat is showing the stat from last last 5
min or 1 min or what ever elapsed time.

But it is becoming difficult to understand this. since I'm not sure how many
clients has got served 2xx during the particular time.


 epoch 2xx
3xx4xx  5xx
PUTVAL test.example.com/haproxy/haproxy_backend-example
1371198785:45511301:98:26038:31575275:13471396:363095:100026:0:0:79:0:79789
PUTVAL test.example.com/haproxy/haproxy_backend-example
1371198795:42791104:67:24597:29708693:12645578:339827:95649:0:0:70:0:74804
PUTVAL test.example.com/haproxy/haproxy_backend-example
1371198806:42791857:67:24597:29709185:12645831:339837:95649:0:0:69:0:74804
PUTVAL test.example.com/haproxy/haproxy_backend-example
1371198816:41279933:77:23783:28669637:12186636:327477:94791:0:0:82:0:71402
PUTVAL test.example.com/haproxy/haproxy_backend-example
1371198826:42793399:67:24597:29710228:12646304:339855:95650:0:0:68:0:74804
PUTVAL test.example.com/haproxy/haproxy_backend-example
1371198836:42434557:62:24019:29566746:12441335:333463:91580:0:0:68:0:74536
PUTVAL test.example.com/haproxy/haproxy_backend-example
1371198846:42946664:67:24746:29825328:12683434:340971:95572:0:0:82:0:74749
PUTVAL test.example.com/haproxy/haproxy_backend-example
1371198856:42436066:62:24019:29567729:12441842:333486:91583:0:0:68:0:74536
PUTVAL test.example.com/haproxy/haproxy_backend-example
1371198866:42796417:67:24600:29712213:12647285:339903:95658:0:0:74:0:74804
PUTVAL test.example.com/haproxy/haproxy_backend-example
1371198876:41230675:69:23321:28667585:12141642:327160:92959:0:0:71:0:71350


I don't know how you produced that, as it doesn't seem to be in a
format that HAProxy produces. (I may be wrong here, of course!)

May I suggest you examine the raw stats in their CSV format? There may
be an error creeping in to your CSV->Data transform stage.

Jonathan



--
- Ashish

Re: haproxy mysql-check

[Nenad Merdanovic]

Hello,

I have tracked this down to the new authentication method used in MySQL
5.6 since version 5.6.6.

Verify this for the user you specified in option mysql-check:

select plugin from mysql.user where user='monitor' \G
*** 1. row ***
plugin: sha256_password
1 row in set (0.00 sec)

If you see sha256_password, it won't work.

Since password authentication is not used in health checks by HAproxy,
you can just create a new user that is not using this kind of
authentication to be used by the HAproxy:

CREATE USER monitor@ IDENTIFIED WITH 'mysql_native_password';

Verify it is working by doing:

select plugin from mysql.user where user='monitor' \G
*** 1. row ***
plugin: mysql_native_password
1 row in set (0.00 sec)


Let me know if this fixes the issue.

Regards,
Nenad


On 06/17/2013 01:50 PM, Jayadevan M wrote:
> Hi,
> 
>> listen stats :1936
>> mode http
>> stats enable
>> stats realm Haproxy\ Statistics
>> stats uri /
>>
>> frontend  mysql_proxy *:3309
>> mode tcp
>> default_backend request_mysql
> One error to another - How can I make HAProxy use a new MySQL 
> client/libraries? I am getting the error -
> 
> [WARNING] 167/224803 (20008) : Server request_mysql/svr1 is DOWN, reason: 
> Layer7 wrong status, code: 0, info: "Client does not support authentication 
> protocol requested by server; consider upgrading MySQL client", check 
> duration: 2ms. 0 active and 0 backup servers left. 0 sessions active, 0 
> requeued, 0 remaining in queue.
> 
> I have MySQL 5.6.10
> 
> Regards,
> Jayadevan
> 
> 
> DISCLAIMER: "The information in this e-mail and any attachment is intended 
> only for the person to whom it is addressed and may contain confidential 
> and/or privileged material. If you have received this e-mail in error, kindly 
> contact the sender and destroy all copies of the original communication. IBS 
> makes no warranty, express or implied, nor guarantees the accuracy, adequacy 
> or completeness of the information contained in this email or any attachment 
> and is not liable for any errors, defects, omissions, viruses or for 
> resultant loss or damage, if any, direct or indirect."
> 

-- 
Nenad Merdanovic | PGP: 0x423edcb2 | Web: http://nimzo.info
Linkedin: http://www.linkedin.com/in/nenadmerdanovic

Re: [ANNOUNCE] haproxy-1.5-dev19 and 1.4.24 (security update)

[Cyril Bonté]

Hi all,

Le 17/06/2013 16:24, Willy Tarreau a écrit :

Hi all,

Here's an important update for 1.4 and 1.5, please read it, it contains
an important security fix.

When a config makes use of hdr_ip(x-forwarded-for,-1) or any such thing
involving a negative occurrence count, the header is still parsed in the
order it appears, and an array of up to MAX_HDR_HISTORY entries is created.
When more entries are used, the entries simply wrap and continue this way.

A problem happens when the incoming header field count exactly divides
MAX_HDR_HISTORY, because the computation removes the number of requested
occurrences from the count, but does not care about the risk of wrapping
with a negative number. Thus we can dereference the array with a negative
number and randomly crash the process.

The bug is located in http_get_hdr() in haproxy 1.5, and get_ip_from_hdr2()
in haproxy 1.4. It affects configurations making use of one of the following
functions with a negative  occurence number :

- hdr_ip(, )  (in 1.4)
- hdr_*(, )   (in 1.5)

It also affects "source" statements involving "hdr_ip()" since that
statement implicitly uses -1 for  :

- source 0.0.0.0 usesrc hdr_ip()

A workaround consists in rejecting dangerous requests early using
hdr_cnt(), which is available both in 1.4 and 1.5 :

block if { hdr_cnt() ge 10 }

This bug has been present since the introduction of the negative offset
count in 1.4.4 via commit bce70882. It has been reported by David Torgerson
who offered some debugging traces showing where the crash happened, thus
making it significantly easier to find the bug!

CVE-2013-2175 was assigned to this bug.


Some monthes ago, I developed a patch to add IP geolocation support to 
haproxy :

https://github.com/cbonte/haproxy-patches/wiki/Geolocation

I didn't take time to publish it on the mailing list, so I'm not sure it 
is used by others, but in case it is, I strongly recommend to upgrade to 
haproxy 1.4.24 or 1.5-dev19, as it also uses http_get_hdr() when 
matching an IP against an HTTP header.


For the short story, after discussing with Willy, we decided not to 
include it directly in haproxy. This will let us introduce some 
improvements in the configuration file syntax after 1.5 is released.



--
Cyril Bonté

RE: Single Source Multicast load balancing

[Steve Ryder]

Hi Lukas,

Thank you. Is this for certain or are you making an educated guess? 

I do see that there are ways to LB multicast traffic in general but nothing 
about HA Proxy being able to so I suspect this is accurate but I'm trying to 
dig for more. 

I need to come up with a way to LB SSM MC traffic if at all possible. 

Thanks again,
-Steve


  

RE: Single Source Multicast load balancing

[Lukas Tribus]

Hi Steve,

I don't think this will be possible, since HAProxy can only load-balance
TCP traffic and I guess thats a showstopper for your use-case. If not,
kindly share some details.



Regards,

Lukas <>

Re: Product order access for

[小欧]

As an imprtant member,
I've reserved you a special
download access link to a new tool
that allows you to "take" commissions 
using your moible phone.
http://url7.me/wkJu
If you don't have one, then 
ignore this email

Single Source Multicast load balancing

[Steve Ryder]

Hi,

I am looking to use HA proxy to load balance a couple of video streaming 
servers. I am just beginning this process and am wondering if there are any 
show stoppers or hurdles that I might encounter when trying to load balance a 
couple of servers that are dependent upon SSM?

In theory, I think HA proxy will do what we need it to do but I am about to 
begin a proof of concept to see if it will work or not. If so, we plan on 
deploying this across many of our clients solutions. At least that's what I'd 
like to do if we can pass the POC.

So far, I like what HA proxy can do but I'm not certain yet this will work for 
us.

Any ideas or suggestions would be most appreciated.

Thank you,
-Steve


Steven Ryder
Solutions Architect

[cid:image001.jpg@01CE5623.8069BB20]

6825 Flanders Drive
San Diego, CA  92121
(858) 677-7800
www.verimatrix.com

This communication may contain information that is confidential in nature and 
unauthorized use or disclosure is strictly prohibited.  If you are not the 
intended recipient, kindly reply or call at the number above to alert us. 
Afterward, please delete this communication in its entirety.

<>

Re: Spy a cell phone anywhere in the world.

[haproxy]

i looked the blog copy9blog.com ;)

---
posted at http://www.serverphorums.com
http://www.serverphorums.com/read.php?10,343992,726779#msg-726779

[ANNOUNCE] haproxy-1.5-dev19 and 1.4.24 (security update)

[Willy Tarreau]

Hi all,

Here's an important update for 1.4 and 1.5, please read it, it contains
an important security fix.

When a config makes use of hdr_ip(x-forwarded-for,-1) or any such thing
involving a negative occurrence count, the header is still parsed in the
order it appears, and an array of up to MAX_HDR_HISTORY entries is created.
When more entries are used, the entries simply wrap and continue this way.

A problem happens when the incoming header field count exactly divides
MAX_HDR_HISTORY, because the computation removes the number of requested
occurrences from the count, but does not care about the risk of wrapping
with a negative number. Thus we can dereference the array with a negative
number and randomly crash the process.

The bug is located in http_get_hdr() in haproxy 1.5, and get_ip_from_hdr2()
in haproxy 1.4. It affects configurations making use of one of the following
functions with a negative  occurence number :

   - hdr_ip(, )  (in 1.4)
   - hdr_*(, )   (in 1.5)

It also affects "source" statements involving "hdr_ip()" since that
statement implicitly uses -1 for  :

   - source 0.0.0.0 usesrc hdr_ip()

A workaround consists in rejecting dangerous requests early using
hdr_cnt(), which is available both in 1.4 and 1.5 :

   block if { hdr_cnt() ge 10 }

This bug has been present since the introduction of the negative offset
count in 1.4.4 via commit bce70882. It has been reported by David Torgerson
who offered some debugging traces showing where the crash happened, thus
making it significantly easier to find the bug!

CVE-2013-2175 was assigned to this bug.

For those who want to quickly deploy a fix, please use this patch for 1.5,
it also applies to 1.4 :

   http://git.1wt.eu/web?p=haproxy.git;a=commitdiff;h=67dad2715b

1.4.24 has only two other fixes from 1.4.23 :
  - BUG/MEDIUM: checks: disable TCP quickack when pure TCP checks are used
  - BUG/MAJOR: backend: consistent hash can loop forever in certain 
circumstances

For 1.5, no less than 28 bugs were fixed since 1.5-dev18, but as usual, either
you were not affected by them or were already using a more recent snapshot :-)
 
Bugs apart, 1.5 has received long-awaited updates, among which :

  - error reporting for acl/fetch was improved, log-format can now indicate
where a bad keyword was detected ;

  - the stats page allow the output to be filtered to certain proxies only 

  - transparent proxy is now supported on FreeBSD/OpenBSD

  - new ACL fetch full_hdr() works on a full header line, as opposed to
hdr() which works on a comma-delimited list of values. This is useful
with some new user-agents which include commas and could not be matched ;

  - health-checks try to drain server response first to avoid to emit a
TCP reset whenever possible ;

  - new "http-response" rule sets allows some processing to be performed
based on the response (eg: add/set header) ;

  - new actions for http-request/http-response :
+ set-nice : change the task's priority : allows high-bandwidth,
  low importance tasks to be deprioritized (useful for compression
  as well) ;

+ set-log-level : change the log level of current request, with
  possibility to completely disable it (eg: log POSTs with higher
  severity or stop logging statics, etc...) ;

+ set-tos : set the DSCP field of outgoing packets to the specified
  value. Can be useful to route certain responses over different
  links ;

+ set-mark : set a netfilter mark on all outgoing packets to the
  specified value. Can be used as an alternative to DSCP above, or
  to blacklist some IPs (when combined with ipset for example) ;

  - new action "expect-proxy layer4" for "tcp-request connection". This
allows the PROXY protocol to be conditionally enabled on incoming
connections. For example, when you rely on an external haproxy farm
whose addresses are known, the PROXY protocol can be enabled just
for them.

  - a new "env()" fetch keyword was added to retrieve an environment
variable. This allows a same config to be used in various modes by
just changing an environment variable during a reload (eg: prod/maint).
Other usages include passing the Via header to servers.

  - stick-counters have been increased to 3 (sc0, sc1, sc2), because most
often when combining to criteria, it was not possible to have both 1,
2 and 1+2 at the same time.

  - ACL usage simplification : fetch methods of types boolean, integer
or IP address are automatically usable in ACLs without having to
specify "-m $type". This permitted to significantly clean the code
by removing many double references to same keywords. Contributors
will probably appreciated.

  - the ACL/fetch doc experienced a major lift up to avoid referencing the
same keywords twice. It was by far the hardest change of this whole
version!

I receive about twice a week a question asking "when will 1.5 become stabl

Re: haproxy mysql-check

[Willy Tarreau]

Hi Jayadevan,

On Mon, Jun 17, 2013 at 11:50:10AM +, Jayadevan M wrote:
> One error to another - How can I make HAProxy use a new MySQL 
> client/libraries?

Haproxy doesn't use a mysql library, it only does health checks and
verifies the handshake.

> I am getting the error -
> 
> [WARNING] 167/224803 (20008) : Server request_mysql/svr1 is DOWN, reason: 
> Layer7 wrong status, code: 0, info: "Client does not support authentication 
> protocol requested by server; consider upgrading MySQL client", check 
> duration: 2ms. 0 active and 0 backup servers left. 0 sessions active, 0 
> requeued, 0 remaining in queue.

You should specify a username with the check I believe, please look at
"option mysql-check" in the doc, it includes an example of how to set it
up.

Hoping this helps,
Willy

RE: haproxy mysql-check

[Jayadevan M]

Hi,

> listen stats :1936
> mode http
> stats enable
> stats realm Haproxy\ Statistics
> stats uri /
>
> frontend  mysql_proxy *:3309
> mode tcp
> default_backend request_mysql
One error to another - How can I make HAProxy use a new MySQL client/libraries? 
I am getting the error -

[WARNING] 167/224803 (20008) : Server request_mysql/svr1 is DOWN, reason: 
Layer7 wrong status, code: 0, info: "Client does not support authentication 
protocol requested by server; consider upgrading MySQL client", check duration: 
2ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 
remaining in queue.

I have MySQL 5.6.10

Regards,
Jayadevan


DISCLAIMER: "The information in this e-mail and any attachment is intended only 
for the person to whom it is addressed and may contain confidential and/or 
privileged material. If you have received this e-mail in error, kindly contact 
the sender and destroy all copies of the original communication. IBS makes no 
warranty, express or implied, nor guarantees the accuracy, adequacy or 
completeness of the information contained in this email or any attachment and 
is not liable for any errors, defects, omissions, viruses or for resultant loss 
or damage, if any, direct or indirect."

Re: haproxy mysql-check

[Willy Tarreau]

On Mon, Jun 17, 2013 at 06:57:15AM +, Jayadevan M wrote:
> HI,
> 
> >It should not because as you can see in the trace, the whole check happens in
> >only 2 milliseconds, which is quite fast. What are the other parameters you
> >changed ? Could you also please share all your timeouts ? Maybe some of
> >them are wrong ?
> >
> I am getting a layer 4 timeout in the environment where I should get this 
> running. Here is my file -
> global
> pidfile /var/run/haproxy1.pid
> stats socket /tmp/haproxy
> defaults
> log global
> timeout connect 5 # default 10 second time out if a backend is not 
> found
> timeout client  3
> timeout server  3

What timeout did you have before "timeout connect 5" ? Do you think it's
possible that you've had "timeout connect 10" ? Then it would be 10 ms and
might explain what it failed (and running via strace can add enough latency
to make it work more often or fail more often depending how things go).

> listen stats :1936
> mode http
> stats enable
> stats realm Haproxy\ Statistics
> stats uri /
> 
> frontend  mysql_proxy *:3309
> mode tcp
> default_backend request_mysql
> 
> backend request_mysql
> mode tcp
> option mysql-check user haproxy
> server svr2 192.168.8.37:3406  weight 1 check port 3406 inter 5000 
> rise 3 fall 3
> server svr1 192.168.2.27:3306  weight 1 check port 3306 inter 5000 
> rise 3 fall 3
> 
> Please note that the IPs have changed and now they are both windows machines.

OK. Anyway your config is OK in my opinion.

> Do we need MySQL client to be installed on the m/c for this to work?

no, not at all.

Best regards,
Willy