Re: Block clients based on header in real time?

2013-06-12 Thread Ricardo Fraile
Fantastic!

Whith this conf, now, i can update the list with a simple:
# echo set table name-of-the-table key 10.0.0.1 data.gpc0 1 | socat stdio 
/var/run/haproxy.sock


And with a curl:
$ curl -I 127.0.0.1:80 -H True-Client-IP: 10.0.0.1
HTTP/1.0 403 Forbidden
Cache-Control: no-cache
Connection: close
Content-Type: text/html

But one question more, if i need to block a subnet, how can i do it? I try to 
store:
echo set table name-of-the-table key 10.0.0.0/8 data.gpc0 1 | socat stdio 
/var/run/haproxy.sock

but not work, and the same with only 10. in the same place of 10.0.0.0/8 
but nothing.

Thanks, 




 De: Baptiste bed...@gmail.com
Para: Ricardo Fraile rfra...@yahoo.es 
CC: haproxy@formilux.org haproxy@formilux.org 
Enviado: Sábado 8 de junio de 2013 8:40
Asunto: Re: Block clients based on header in real time?
 

Hi Ricardo,

Actually, this is how I would do the conf:
  stick-table type ip size 1m store gpc0
  tcp-request content track-sc1 req.hdr_ip(True-Client-IP)
  http-request deny if { sc1_get_gpc0 gt 0 }


Then you can insert new data in the stick table using HAProxy UNIX
socket (which can run over TCP) with:
  set table table key key data.data_type value
In example, to block 10.0.0.1:
  set table mybackend key 1.0.0.1 data.gpc0 1

And you're done.

Here is the result when I test it with curl on my laptop:

$ curl 127.0.0.1:8080 -H True-Client-IP: 10.0.0.1

htmlbodyh1403 Forbidden/h1
Request forbidden by administrative rules.
/body/html


$ curl 127.0.0.1:8080

htmlbodyh1503 Service Unavailable/h1
No server is available to handle this request.
/body/html


Baptiste


On Thu, May 30, 2013 at 12:50 PM, Ricardo Fraile rfra...@yahoo.es wrote:
 Hello,

    Ok, i update the server to 1.5 version but i have some troubles between 
stick-table and the acl.

    Before, i had:

 listen host1 *:80
     ...
     mode http
     acl block_invalid_client hdr_sub(True-Client-IP) -f true-client-ip.lst
     block if block_invalid_client
     ...

    Now, i try to change the file to a stick table:

 backend host1
     ...

     stick-table type ip size 1m store gpc0
     acl block_invalid_client hdr_ip(True-Client-IP) -- { stick match(host1) }
     http-request deny if block_invalid_client
     ...

     But not work:

     error detected while parsing ACL 'block_invalid_client' : '{' is not a 
valid IPv4 or IPv6 address.
     error detected while parsing an 'http-request deny' condition : no such 
ACL : 'block_invalid_client'.


     ¿Is it possible to match http header inside an acl to a stick table?

 Thanks,




 - Mensaje original -
 De: Baptiste bed...@gmail.com
 Para: Ricardo Fraile rfra...@yahoo.es
 CC: haproxy@formilux.org haproxy@formilux.org
 Enviado: Miércoles 29 de Mayo de 2013 14:51
 Asunto: Re: Block clients based on header in real time?

 Hi,

 With latest HAProxy version, you could use a stick table and insert
 IPs in the stick table through HAProxy socket.
 Then you can ban all IPs from the stick table.

 Baptiste


 On Wed, May 29, 2013 at 1:05 PM, Ricardo Fraile rfra...@yahoo.es wrote:
 Hello,


    I'm looking for a solution for blocking users based on a header, 
x-forwarded-for. I have yet an acl for this but is it possible to update the 
list of ips without restart haproxy?


 Thanks,



Meaning of hrsp_2xx in show_stat

2013-06-12 Thread Ashish Jaiswal

Hi All,

I'm trying to collect some statistics of haproxy server. Here is what 
I'm not able to understand.

If possible any body can help me out with this.

This is the command which is running and giving stats to collectd and 
the graphs are generated on graphite.

echo 'show stat' | socat - UNIX-CLIENT:$sock 


The problem is that the rate is showing something different and the 
hrsp_2xx is showing something different.
Can any one have any idea how does the htsp_2xx stats are collected from 
haproxy. I mean whether it is per seconds/hits all through the logs or 
anything.


This is what it is there in 
http://haproxy.1wt.eu/download/1.4/doc/configuration.txt


# 33. rate: number of sessions per second over last elapsed second
# 39. hrsp_1xx: http responses with 1xx code
# 40. hrsp_2xx: http responses with 2xx code
# 41. hrsp_3xx: http responses with 3xx code
# 42. hrsp_4xx: http responses with 4xx code
# 43. hrsp_5xx: http responses with 5xx code

I can share the script if any body wants to have a look.

--
- Ashish




мыслите иметься превосходнейшим партнером?

2013-06-12 Thread Артем Глебович
  Любая мадам изведает Оргазм http://goo.gl/yTqWt?/QDuw?/uIMizbC 



Re: Meaning of hrsp_2xx in show_stat

2013-06-12 Thread Jonathan Matthews
On 12 June 2013 10:20, Ashish Jaiswal ash...@trellian.com wrote:
 The problem is that the rate is showing something different and the
 hrsp_2xx is showing something different.
[snip]
 # 33. rate: number of sessions per second over last elapsed second

This is what it says it is: sessions/sec over the last second.

 # 39. hrsp_1xx: http responses with 1xx code
 # 40. hrsp_2xx: http responses with 2xx code
 # 41. hrsp_3xx: http responses with 3xx code
 # 42. hrsp_4xx: http responses with 4xx code
 # 43. hrsp_5xx: http responses with 5xx code

These are absolute incremental counters over the lifetime of the
HAProxy process.

I don't think the 2 (rate  counters) are directly comparable, and I'd
definitely expect them to show different values.

HTH,
Jonathan
--
Jonathan Matthews // Oxford, London, UK
http://www.jpluscplusm.com/contact.html



RE: HAProxy latest on SSL

2013-06-12 Thread Lukas Tribus
 IMHO, it's confusing having clear and SSL backends defined

I do see your point, but I would rather not introduce another configuration
option like use-server (a new user probably doesn't know about ssl_fc and
conditional options either).

What about removing the clear-text options and make a dedicated clear-text
frontend which uses the https-backend. That way we give the users a
immediate understanding of the fact that ssl processing is fully decoupled
from the request processing itself; but we also avoid mixed front and
backends, which is whats causing confusion here.

It would then look like this I guess:

frontend my-http-frontend
    bind :80
    default_backend my-https-backend

frontend my-https-frontend
    # primary cert is /etc/cert/server.pem
    # /etc/cert/certdir/ contains additional certificates for SNI clients
    bind :443 ssl crt /etc/cert/server.pem crt /etc/cert/certdir/
    default_backend my-https-backend

backend my-https-backend
    # a https backend
    server s4 10.0.0.3:443 ssl


RE: odd 10 seconds in websocket negotiation with more than one backend server

2013-06-12 Thread Lukas Tribus
Hi Ramin,

 When I have two servers in the backend haproxy makes connections to both
 websocket backends and exactly 10 seconds after the client had
 negotiated the connection to haproxy the client considers itself
 connected to socket.io application.

This is very odd, but I also have to admit I don't know anything about
websocket. Could you start haproxy in debug mode, reproduce it and post the
debug output?


Lukas 


RE: CPU spike after restarting with -sf pid

2013-06-12 Thread Lukas Tribus
 Is the latest snapshot really what you recommend for running in production?

That depends ;)

The thing is, if you already run the development branch (1.5), its likely
that a snapshot contains more bugfixes - which you may be interested in
(like [1]). Of course a snapshot on the other hand is more likely to be
broken than a -dev releases.

Personally I decide whether to use a -dev release or a snapshot by reading
the snapshots changelog (or the git log): if a big change (like a fancy new
feature) has been committed recently, then you probably want to avoid it for
your big production box, and give it some time. But when the branch is calm
for a bit or has seen only minor fixes or changes, then the snapshot is
probably worth a shot.

For example the current git tree contains 12 patches from the last 48 hours :
I would refrain from putting it in production for mission critical services
without carefully testing it first.


If you are isolating a bug on a non-production box however, I suggest you
try this with a snapshot.


Keep in mind that if no one uses the development branch, no one will report
bugs and that will ultimately lead to a literally unstable development
branch. The more users run recent code and report bugs in the 1.5 branch,
the more stable it will become.

If you run a -dev release, I suggest you run the latest -dev available.


Regards,

Lukas


[1] 
http://haproxy.1wt.eu/git?p=haproxy.git;a=commitdiff;h=379357af5842e1cfa176b06165268d6c48f34631
   


Re: CPU spike after restarting with -sf pid

2013-06-12 Thread Willy Tarreau
Hi Malcolm,

On Tue, Jun 11, 2013 at 12:01:25AM +, Malcolm Handley wrote:
 That's sound advice. We'll upgrade soon and see whether anything changes.
 
 Is the latest snapshot really what you recommend for running in production? I
 was nervous about using a dev release but we desperately needed support for
 the proxy protocol.

You're right to feel nervous :-)

That said, Lukas is right on this point, and the issue you're talking about
was fixed in dev18 :

  commit cf181c9d404815f890da7cd2243a5528edd7b4f9
  Author: Willy Tarreau w...@1wt.eu
  Date:   Fri Jan 18 15:22:41 2013 +0100

BUG/MINOR: epoll: use a fix maxevents argument in epoll_wait()

epoll_wait() takes a number of returned events, not the number of
fds to consider. We must not pass it the number of the smallest fd,
as it leads to value zero being used, which is invalid in epoll_wait().
The effect may sometimes be observed with peers sections trying to
connect and causing 2-seconds CPU loops upon a soft reload because
epoll_wait() immediately returns -1 EINVAL instead of waiting for the
timeout to happen.

This fix should be backported to 1.4 too (into ev_epoll and ev_sepoll).

The fix was backported into 1.4.23 as well, so you can use it with Cyril's
proxy protocol patch. BTW, I seem to have finished merging fixes, so I'll
soon issue a dev19 and 1.4.24.

Best regards,
Willy

 
 
 On Fri, Jun 07, 2013 at 03:16 PM, Lukas Tribus luky...@hotmail.com wrote:
  Hi Malcolm,
  
  
   This works but we find that the new haproxy process uses a lot of cpu
   (100% of one core) for about 20 seconds after the restart. During this
   time it looks as if various queues fill up and haproxy logs fewer
   requests than normal. Once the cpu load drops we get a surge of
   requests (which cause a spike in connections to our db, and a raft of
   other problems if we do this during heavy traffic).
  
  I strongly suggest to update your code to a more recent release, there
  have been a lot of bug fixes since dev15.
  
  Grab dev18 or better yet, the latest snapshot.
  
  
  It doesn't make sense to start troubleshooting on those obsolete releases,
  especially in the development branch.
  
  
  Lukas