Pop / Imap Haproxy
Hello, We are trying to setup haproxy for pop and Imap, so I was wondering if we could have the originating IPs using POP/IMAP procotols just like x-forwarded-for for HTTP? Thanks, Anil
Re: Pop / Imap Haproxy
You can use the 'proxy protocol' - but you will have to insure that your target pop/imap daemons are aware of it. -- Nathan On 06/19/2015 04:01 PM, anil kumar wrote: Hello, We are trying to setup haproxy for pop and Imap, so I was wondering if we could have the originating IPs using POP/IMAP procotols just like x-forwarded-for for HTTP? Thanks, Anil -- Nathan Neulinger nn...@neulinger.org Neulinger Consulting (573) 612-1412
découvrez votre offre
Si le message ne s'affiche pas correctement merci de suivre ce [1]lien References 1. http://clicks.deal-actuel.com/v/NC/wraQlh7ZPhKAOCSqC7oPH3/a83bd420 [1]Histoire d'Or Vivez un Noël en Grand grâce au premier bijoutier de France [2]1er bijoutier de France [3]BIJOUX [4]MONTRES [5]IDÉES CADEAUX [6]Histoire d'or vous souhaite la bienvenue ! [7]PROFITEZ D'ORES ET DÉJÀ DE VOTRE OFFRE DE BIENVENUE : [8]LIVRAISON GRATUITE AVEC LE CODE BIENVENUE [9]Offre reservée à haproxy@formilux.org [10]Bienvenue chez le premier bijoutier de France ! A la recherche de brillantes idées cadeaux pour Noël ? Découvrez nos collections de bijoux, il y en a pour tous les goûts : plus de 2 500 bijoux en or ou en argent vous attendent. Ne manquez pas nos montres de grandes marques, plus de 500 modèles disponibles pour trouver le vôtre ! N’hésitez plus et rendez-vous sur histoiredor.com ! Achetez vos cadeaux en ligne en toute sérénité : paiement sécurisé, garantie deux ans sur tous nos bijoux, nous avons pensé à tout. Votre achat ne convient pas ? Vous bénéficiez de 30 jours pour nous faire votre retour et être remboursé intégralement. [11]À tout de suite ! [12]JE DÉCOUVRE [13]4 BONNES RAISONS POUR NE PLUS HÉSITER [14]Paiement 100% sécurisé [15]Retrait GRATUIT sous 2h en magasin [16]Retour GRATUIT sous 30 jours [17]Livraison garantie avant Noël [pix.gif?eml-publisher=natexoeml-name=noel14-prm1_bienvenueea-rnd=[R ANDOM]] [imp?type(inv)g(22282168)a(2463532)] References Visible links 1. http://clicks.deal-actuel.com/c/NC/sr/wraQlh7ZPhKAOCSqC7oPH3/b/PgX/2e8cc255://ea.histoiredor.com/dynclick/histoiredor/?eml-publisher=natexoeml-name=noel14-prm1_bienvenueeurl=http%3A%2F%2Fwww.histoiredor.com%2Ffr%2Fhistoire-or%3Futm_source%3Dnatexo%26utm_medium%3Dshoot%26utm_content%3Dprm1_bienvenue%26utm_campaign%3Dnoel14-prm 2. http://clicks.deal-actuel.com/c/NC/sa/wraQlh7ZPhKAOCSqC7oPH3/b/PgX/175b3013://ea.histoiredor.com/dynclick/histoiredor/?eml-publisher=natexoeml-name=noel14-prm1_bienvenueeurl=http%3A%2F%2Fwww.histoiredor.com%2Ffr%2Fhistoire-or%3Futm_source%3Dnatexo%26utm_medium%3Dshoot%26utm_content%3Dprm1_bienvenue%26utm_campaign%3Dnoel14-prm 3. http://clicks.deal-actuel.com/c/NC/sn/wraQlh7ZPhKAOCSqC7oPH3/b/PgX/ff5a0295://ea.histoiredor.com/dynclick/histoiredor/?eml-publisher=natexoeml-name=noel14-prm1_bienvenueeurl=http%3A%2F%2Fwww.histoiredor.com%2Ffr%2Fbijoux%2Fpar-famille%3Futm_source%3Dnatexo%26utm_medium%3Dshoot%26utm_content%3Dprm1_bienvenue%26utm_campaign%3Dnoel14-prm 4. http://clicks.deal-actuel.com/c/NC/sj/wraQlh7ZPhKAOCSqC7oPH3/b/PgX/916043ce://ea.histoiredor.com/dynclick/histoiredor/?eml-publisher=natexoeml-name=noel14-prm1_bienvenueeurl=http%3A%2F%2Fwww.histoiredor.com%2Ffr%2Fmontres%2Fpar-marque%3Futm_source%3Dnatexo%26utm_medium%3Dshoot%26utm_content%3Dprm1_bienvenue%26utm_campaign%3Dnoel14-prm 5. http://clicks.deal-actuel.com/c/NC/ss/wraQlh7ZPhKAOCSqC7oPH3/b/PgX/ae6690b3://ea.histoiredor.com/dynclick/histoiredor/?eml-publisher=natexoeml-name=noel14-prm1_bienvenueeurl=http%3A%2F%2Fwww.histoiredor.com%2Ffr%2Fhistoire-or%3Futm_source%3Dnatexo%26utm_medium%3Dshoot%26utm_content%3Dprm1_bienvenue%26utm_campaign%3Dnoel14-prm 6. http://clicks.deal-actuel.com/c/NC/sI/wraQlh7ZPhKAOCSqC7oPH3/b/PgX/0c1fb4ff://ea.histoiredor.com/dynclick/histoiredor/?eml-publisher=natexoeml-name=noel14-prm1_bienvenueeurl=http%3A%2F%2Fwww.histoiredor.com%2Ffr%2Fhistoire-or%3Futm_source%3Dnatexo%26utm_medium%3Dshoot%26utm_content%3Dprm1_bienvenue%26utm_campaign%3Dnoel14-prm 7. http://clicks.deal-actuel.com/c/NC/sN/wraQlh7ZPhKAOCSqC7oPH3/b/PgX/386a04cf://ea.histoiredor.com/dynclick/histoiredor/?eml-publisher=natexoeml-name=noel14-prm1_bienvenueeurl=http%3A%2F%2Fwww.histoiredor.com%2Ffr%2Fhistoire-or%3Futm_source%3Dnatexo%26utm_medium%3Dshoot%26utm_content%3Dprm1_bienvenue%26utm_campaign%3Dnoel14-prm 8. http://clicks.deal-actuel.com/c/NC/sg/wraQlh7ZPhKAOCSqC7oPH3/b/PgX/a3c4d2c5://ea.histoiredor.com/dynclick/histoiredor/?eml-publisher=natexoeml-name=noel14-prm1_bienvenueeurl=http%3A%2F%2Fwww.histoiredor.com%2Ffr%2Fhistoire-or%3Futm_source%3Dnatexo%26utm_medium%3Dshoot%26utm_content%3Dprm1_bienvenue%26utm_campaign%3Dnoel14-prm 9. http://clicks.deal-actuel.com/c/NC/s5/wraQlh7ZPhKAOCSqC7oPH3/b/PgX/4fe87890://ea.histoiredor.com/dynclick/histoiredor/?eml-publisher=natexoeml-name=noel14-prm1_bienvenueeurl=http%3A%2F%2Fwww.histoiredor.com%2Ffr%2Fhistoire-or%3Futm_source%3Dnatexo%26utm_medium%3Dshoot%26utm_content%3Dprm1_bienvenue%26utm_campaign%3Dnoel14-prm 10.
wholesale price 150W LED high bay
Hello, Wesupplyledlampwithhigh=qualityandcompetitiveprice.Hopetocooperatewithyou. BestRegards -- =KathyWu Skype:kathystar11 JINWANGOptoelectronicsCo.,Limited T:0=086075533165048
Re: HAProxy as a TCP Fast Open Client
I have a scenario to use client mode, is TFO client mode ready to merge to 1.6 dev? Bests, -Igor On Fri, Feb 14, 2014 at 1:47 AM, Willy Tarreau w...@1wt.eu wrote: Hi David, On Thu, Feb 13, 2014 at 01:50:16PM +, David Harrold wrote: Hi Willy Did some more investigation on the case where the application request is too large to fit within the initial SYN. Here is my test setup: Web clients ?? haproxy ?? long-thin-pipe ? haproxy--? web servers TFO Client TFO Server Client sends an HTTP request larger than MSS, the client side haproxy uses TFO and puts as much data as possible within the initial SYN. When SYN ACK is returned, the remaining request data is sent. On closer inspection although the correct number of octets are sent, the octets in the continuation packet are all NUL. E.g. Debug shows 1500 octets in the call to sendto() and a return value of 1500. Wireshark shows TFO sending 1420 octets in the SYN. After SYN ACK comes back, 80 octets are sent in the next packet, but these 80 octets are all NUL. OK so that's clearly a bug below. Looks like something broken in the TFO client, but would be good to see if others can duplicate my results. I?m testing using VMware which I think emulates TCP offload by default, wondering whether that could be the cause? Could be indeed, we've got a few issues with GRO/GSO in the past as well. I'll have to run some tests with your patch to see with different kernels if I can reproduce the same issue. It is also possible that it was a known old bug that's already fixed but not backported to some stable branches. Regarding default values for the TFO backlog - I was concerned that if this is maxconn then is there a DoS vulnerability? Eg if a TFO client streams SYNs with random data at you, each of these ties up an haproxy connection for a while, starving other clients? But it's the same with real connections in practice, because even when the connection is accepted, we still need to parse it. This is also the reason for having a short http-request timeout. For example, if you support 100k concurrent connections on the frontend and wait for a request for 5 seconds, a client will have to send 20k conns/s to keep you full. In practice, even at this rate, you'll accept 100k extra conns in the backlog which will get served but will have to wait 0 to 5s on average. The worst thing to do is to reduce the accept rate, which lowers the bar for attackers. The higher the limit, the more information we have for dealing with pending data. One of the easy things we are already able to do is count the number of concurrent connections per source address for example. Something we cannot do if we refrain from accepting these connections. I also have some memories about the network stack defending itself when a SYN queue overflows, it would reject TFO or accelerate the regeneration of cookies, I don't remember exactly. Cheers, Willy
Spam
Hello, It is possibly to stop the spam which arrives here in the mailing list often? Greetings Roger Roger Sikorski Auszubildender Fachinformatiker Systemintegration RR Ice Cream Deutschland GmbH Eduard Pestel Str. 15 49080 Osnabrück Fax: +49 541 301 www.rr-icecream.euhttp://www.rr-icecream.eu/ roger.sikor...@de.rr-icecream.eumailto:roger.sikor...@de.rr-icecream.eu Handelsregister Amtsgericht Osnabrück HRB 17067 Sitz der Gesellschaft: Osnabrück Ident Nr. DE 117657534 Geschäftsführer: Dr. Ibrahim Najafi, Dr. Gotthard Kirchner P Before you print think about the ENVIRONMENT This e-mail has been scanned for viruses by RR Ice Cream. The service is powered by MessageLabs.
Re: Rate limiting on part of the URL path
Hi,
I actually am able to insert the string in the table and increase the
http_req_rate:
# table: HTTP, type: string, size:1048576, used:2
0x188193c: key=abc123 use=0 exp=3574082 http_req_rate(6)=4
0x1896f6c: key=abc_567 use=0 exp=3596948 http_req_rate(6)=17
My problem is that connections or requests should be refused if
http_req_rate is greater or equal to 10 however as you can see the rate for
abc_567 is 17 and the requests were still handled.
--
Pierre
On Fri, Jun 19, 2015 at 8:51 AM, bjun...@gmail.com bjun...@gmail.com
wrote:
Hi,
if i understand you correctly, this is the same problem i was having:
http://godevops.net/2015/04/23/haproxy-tracking-multiple-sample-fetches-in-stick-table/
http://marc.info/?t=14082871045r=1w=2
--
Bjoern
2015-06-19 14:37 GMT+02:00 Pierre Beaumier pie...@kkdzo.org:
Hi Bjoern,
I was able to extract the information I need and put it in a table by
creating a custom header from the path and applying some regex but now
I'm
not sure how to actually rate limit based on that.
Here's a trimmed down version of my config.
global
daemon
maxconn 10
defaults
mode http
timeout client 60s
timeout connect 5s
timeout server 60s
frontend HTTP
bind *:80
tcp-request inspect-delay 2s
http-request deny if { sc0_http_req_rate ge 10 }
http-request set-header X-Custom-ABC %[path]
http-request replace-value X-Custom-ABC ^.*(abc.*)/.* \1
stick-table type string size 1m expire 60m store http_req_rate(60s)
acl hap-test_front hdr_reg(host) -i haproxytest.domain.tld
haproxytest3.domain.tld
use_backend HAPTEST if hap-test_front
backend HAPTEST
option httpchk GET /healthcheck HTTP/1.0
http-check expect status 200
tcp-request content track-sc0 hdr(X-Custom-ABC) table HTTP
server web web:80 check inter 5000 fastinter 1000 fall 1
I expected the http-request deny if { sc0_http_req_rate ge 10 } stanza
to
refuse the request however the requests are still getting through and the
counter still increases:
# table: HTTP, type: string, size:1048576, used:2
0x188193c: key=abc123 use=0 exp=3574082 http_req_rate(6)=4
0x1896f6c: key=abc_567 use=0 exp=3596948 http_req_rate(6)=17
Thanks
--
Pierre
On Thu, Jun 18, 2015 at 11:42 AM, bjun...@gmail.com bjun...@gmail.com
wrote:
2015-06-17 15:00 GMT+02:00 Pierre Beaumier pie...@kkdzo.org:
Hello,
I'm using haproxy 1.5.12 and I'm trying to do rate limiting based on a
part
of a URL requested.
Requests I want to track and limit have the following form:
https://host1.domain.tld/field1/field2/morestuff?query……
- field1 is a word like user or data, there are 2 to 4 of them and
they're known to me.
- field2 is what I really want to track, it's formed of 3 letters that
never
change and followed by several characters including lower and upper
case
letters, numbers, dashes (-) and underscores (_). The field length is
not
fixed however it will always be in second position in the path.
Examples
for
this field are abc_PT4gWk-42, abc1234 or abc-vb8WQ_2
My goal is have a table storing these with a counter for each, block
if
we
get more than 10 per second and return an error message like too many
requests. I'd like to be able to query this table to have an idea of
the
abusers, this should be trivial by parsing the output of show table.
I have not been able to generate a config that does something similar
and am
quite confused by the stick store-request which accept path but not
path_reg. Am I actually in the right direction ?
Any help would be greatly appreciated.
Thanks
--
Pierre
Hi Pierre,
can you share your config?
---
Bjoern
Re: Lua testcase.. some 'random' data returned when loading a image.. 1.6dev2
On Fri, 19 Jun 2015 02:05:50 +0200 PiBa-NL piba.nl@gmail.com wrote: Hi guys, I'm sure i am abusing lua for completely wrong thing here. But i do not understand why the result isn't at least consistent.. Ive got a Pinguïns.jpg of 759kB (Default Windows 7 example image).. And have the configuration listed below. When requesting the image from a browser the top of the image looks normal, but further down it starts morphing, or becomes complete garbage.. Increasing bufsize to 30 makes the image show normal when reading and writing the whole image in 1 variable.. Though the buffer is still less than half of the image size.?. What im wondering though is how can it be that the results with smaller bufsizes vary..?? Is it overflowing some memory? With 1.6dev1 it would crash after a few requests, dev2 seems to have fixed that.. Though the random behavior is still strange.. I would expect every time the same image is send it to be cut short at buffsize, or perhaps just work if lua might use its own memory buffers not limited to haproxy's buffsize? Is it a bug? Or just a wrong lua script? Should files / sockets be closed by the script? I get an error if i do..(attempt to use a closed file) Hi, thank you for the repport. I'm currently trying to reproduce it, I'm not finished. I see two errors in your code: First, io.* are real blocking functions. HAProxy is really blocked waiting for the data access. It is a very bad to use it. However, how that you write for the file acces should work. Second, your variable f is not declared as local. This variable is keep between two requests. Maybe is the reason of your problem. To serve static file with Lua, the best practice is loading the full file during the initialisation and store it into a global variable. During the runtime, you will use only the variable and not the file. Thierry global #tune.bufsize 30 tune.lua.session-timeout 10 tune.lua.task-timeout 10 lua-load /var/etc/haproxy/hello_world.lua listen proxy bind :10001 tcp-request content lua hello_image function hello_image(txn) txn.res:send(HTTP/1.1 200 OK\n\n) f = io.open(/var/etc/haproxy/Penguins.jpg, rb) local block = 5000 while true do local bytes = f:read(block) if not bytes then break end txn.res:send(bytes) --core.msleep(25); ## changes behavior to be somewhat more succesfull.. end txn:close() --f:close() ## [ALERT] 168/232309 (74397) : Lua function 'hello_image': runtime error: /var/etc/haproxy/hello_world.lua:8: attempt to use a closed file. end root@OPNsense:/usr/ports/net/haproxy-devel # haproxy -vv HA-Proxy version 1.6-dev2-ad90f0d 2015/06/17 Copyright 2000-2015 Willy Tarreau wi...@haproxy.org Build options : TARGET = freebsd CPU = generic CC = cc CFLAGS = -O2 -pipe -fstack-protector -fno-strict-aliasing -DFREEBSD_PORTS OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_OPENSSL=1 USE_STATIC_PCRE=1 USE_PCRE_JIT=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built with zlib version : 1.2.8 Compression algorithms supported : identity(identity), deflate(deflate), raw-deflate(deflate), gzip(gzip) Built with OpenSSL version : OpenSSL 1.0.2b 11 Jun 2015 Running on OpenSSL version : OpenSSL 1.0.2b 11 Jun 2015 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes Built with PCRE version : 8.35 2014-04-04 PCRE library supports JIT : yes Built with Lua version : Lua 5.3.0 Built with transparent proxy support using: IP_BINDANY IPV6_BINDANY Available polling systems : kqueue : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 3 (3 usable), will use kqueue. -- Thierry FOURNIER thierry.fourn...@arpalert.org
Re: [ANNOUNCE] haproxy-1.6-dev2
It's very cool to have DNS finally! I wonder is that possible to do this like?
use_backend us_upstream if {
hdr(Host),dnsname_to_ip_and_map(geo_us.lst) -m str us }
Convert hostname to IP, find IP's geo info, use matched backend.
Thank you.
Bests,
-Igor
On Thu, Jun 18, 2015 at 4:06 PM, Baptiste bed...@gmail.com wrote:
On Wed, Jun 17, 2015 at 5:08 PM, Willy Tarreau wi...@haproxy.com wrote:
Hi all,
the impatient readers among you will have noticed that it's been almost 3
weeks since I sent the e-mail announcing the imminent release of 1.6-dev2.
That end of merge window has been a nightmare and is not finished, but I
thought it would be wise to issue dev2 anyway so that people can test the
stuff that has been merged anyway. Lesson learned, for 1.7 we'll have a
much shorter merge window so that people don't have enough time to push
that much stuff at the last minute :-)
To be honnest, I'm far from being satisfied with this version. It's as huge
as dev1 (344 commits) despite some things still being pending. Also noticed
quite a number of areas that need to be fixed / cleaned up etc. So at least
the feature freeze is a good thing.
Reading the changelog since 1.6-dev1, in no particular order, I've found :
- DNS-based server name resolution : haproxy is now able to periodically
ask a set of resolvers for the IP address of some servers and to update
them without restarting. This will make life much easier for people
running in AWS where IP address change randomly. Some more stuff was
planned for this such as marking the server as unresolvable if resolving
fails, but we found that people would probably like to have a
configurable
behaviour. Feedback on this is desired and will drive the next steps.
- peers protocol v2 : haproxy 1.6 and 1.5 will not be able to synchronize
their stick tables but on the other hand the new protocol is much better
and more extensible. First it uses a single connection regardless of the
number of tables to synchronize. Second it will support synchronizing
much more than just stick tables. For now it replicates all stick-tables
contents (including gpc, etc...). This allows reloads to keep entries,
rates, etc... as well as to pass them to a backup node in case of a
switchover. It's very likely that during 1.7 development we'll further
extend the amount of information that can be exchanged.
- peers support nbproc 1 as long as they're referenced by a single
process,
and peers sections can be disabled (useful for debugging).
- config : removed a few deprecated keywords (eg: reqsetbe). I wanted to
remove block as well, and appsession. On the first one I'm not sure,
on the second one only Aleks (the author of the feature) provided some
feedback and agreed it was probably time for it to go. Expect that we'd
get rid of them soon if nobody objects.
- pattern cache : a small lru cache applies to pattern matching when it
runs from a list (eg: case insensitive string match, regex, etc). This
can significantly speed up host header matching or regex matching
against a huge list.
- support for stateless zip compression with libslz : this doesn't waste
memory anymore and compresses about 3 times faster than zlib, at a lower
compression ratio.
- support for session/transaction/request/response variables : using the
set-var action in {tcp,http}-{request-response} rulesets, it's possible
to assign the result of a sample expression to a variable allocated on
the
fly and which lasts for all the session, the transaction or just the
ephemeral processing being done on the request or response. This makes
it possible to keep copies of certain request information and reuse them
in the response for example. Some work is still pending on this part,
in particular the ability to use variables with in all arithmetic
converters which currently only take a constant.
- support for declared captures : sometimes it's desired to capture in
the backend or response path but that was not possible since only the
frontend can assign a capture slot. The solution consists in making
it possible to declare a capture slot in the frontend for later use.
- servers: in addition to DNS, it's possible to change a server's IP
address
from the CLI.
- ssl: it's now possible to forge SSL certs on the fly. That's convenient
when haproxy has to be deployed in front of proxies which already work
like this.
- device identification : two companies, 51Degrees and DeviceAtlas,
provided patches to add support for their respective libs. We're
starting to see some demand for such features due to the abundance
of smartphones, tablets and I don't-know-what, and both libs come
with a free device database, so it seems to be the right timing.
The README was updated for
Re: Rate limiting on part of the URL path
Hi Bjoern,
I was able to extract the information I need and put it in a table by
creating a custom header from the path and applying some regex but now I'm
not sure how to actually rate limit based on that.
Here's a trimmed down version of my config.
global
daemon
maxconn 10
defaults
mode http
timeout client 60s
timeout connect 5s
timeout server 60s
frontend HTTP
bind *:80
tcp-request inspect-delay 2s
http-request deny if { sc0_http_req_rate ge 10 }
http-request set-header X-Custom-ABC %[path]
http-request replace-value X-Custom-ABC ^.*(abc.*)/.* \1
stick-table type string size 1m expire 60m store http_req_rate(60s)
acl hap-test_front hdr_reg(host) -i haproxytest.domain.tld
haproxytest3.domain.tld
use_backend HAPTEST if hap-test_front
backend HAPTEST
option httpchk GET /healthcheck HTTP/1.0
http-check expect status 200
tcp-request content track-sc0 hdr(X-Custom-ABC) table HTTP
server web web:80 check inter 5000 fastinter 1000 fall 1
I expected the http-request deny if { sc0_http_req_rate ge 10 } stanza to
refuse the request however the requests are still getting through and the
counter still increases:
# table: HTTP, type: string, size:1048576, used:2
0x188193c: key=abc123 use=0 exp=3574082 http_req_rate(6)=4
0x1896f6c: key=abc_567 use=0 exp=3596948 http_req_rate(6)=17
Thanks
--
Pierre
On Thu, Jun 18, 2015 at 11:42 AM, bjun...@gmail.com bjun...@gmail.com
wrote:
2015-06-17 15:00 GMT+02:00 Pierre Beaumier pie...@kkdzo.org:
Hello,
I'm using haproxy 1.5.12 and I'm trying to do rate limiting based on a
part
of a URL requested.
Requests I want to track and limit have the following form:
https://host1.domain.tld/field1/field2/morestuff?query……
- field1 is a word like user or data, there are 2 to 4 of them and
they're known to me.
- field2 is what I really want to track, it's formed of 3 letters that
never
change and followed by several characters including lower and upper case
letters, numbers, dashes (-) and underscores (_). The field length is not
fixed however it will always be in second position in the path. Examples
for
this field are abc_PT4gWk-42, abc1234 or abc-vb8WQ_2
My goal is have a table storing these with a counter for each, block if
we
get more than 10 per second and return an error message like too many
requests. I'd like to be able to query this table to have an idea of the
abusers, this should be trivial by parsing the output of show table.
I have not been able to generate a config that does something similar
and am
quite confused by the stick store-request which accept path but not
path_reg. Am I actually in the right direction ?
Any help would be greatly appreciated.
Thanks
--
Pierre
Hi Pierre,
can you share your config?
---
Bjoern
Re: Spam
On 19/06/2015 11:08 πμ, Andrei Marinescu wrote: Same here, only 1-2 messages per week, and generally correctly tagged as [SPAM]. Way less than the last discussion on this topic produced J +1 This has been discussed before and Willy expressed the reasons why there isn't any smap filter in the ML. Personally, I am fine with the current setup as gmail does very good job for filtering spam mails for me. My 2cents, Pavlos signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] haproxy-1.6-dev2
On Fri, Jun 19, 2015 at 07:35:49PM +0800, Igor wrote:
It's very cool to have DNS finally! I wonder is that possible to do this like?
use_backend us_upstream if {
hdr(Host),dnsname_to_ip_and_map(geo_us.lst) -m str us }
Convert hostname to IP, find IP's geo info, use matched backend.
Not yet. Maybe later it will be possible but for now the resolution is only
applied to checked servers.
Willy
[SPAM] Re:Your reliable OEM/ODM partner for LED lighting
Hello, my =frined, == = =Greetings fr=om Carina in Shenzhen, China. =We, Simaoled=, are one of major manufacturer of =LED lighting products in China, which co=vering various kinds of LED lig=hting, especially for LED Panel lights, =LED tubes ,LED wall washer lamp amp;nb=sp;LED Floor lighting and other special =LED lighting. =With goodnb=sp;quality, strong production capacity(3000~4000 p=cs flood light per day/1000 pcs LEDnbsp=;panel a day) amp; strong Ramp;D te=am, we warmly welcome OEM amp; ODMnbsp=;projects from you!!! E-catalogue,offer= sheet,testreporteramp;requir=ed certificateswill be provided if ne=eded!Belowplsfindtheinformationof600*600mmLEDpanelligh=t36Wforyourreference: = nbsp=; nb=sp;=nb=sp; MS-PL18323nb=sp;Power =36W Packingdetail=s:4pcs/Carton C=artonSize:L68times;W64times;H18cm GW:14.5kg/Ca=rton UnitPr=iceUS$18.00 Size L597*W5=97*T13mm InputV=oltage AC85-26=5V/AC50/60Hz LEDQTY= 80pcs LEDTyp=e 5630SMD=chip CCT 2700-65=00K Lumen 3200LM Powerf=actor 0.93 CRI(Ra=) Ra#65310;75 =Materia=l PureAl=uminum Lifespa=n gt;50,=000hours Ema=il me or just call me directly, let='s talk detailsThank you!Rgds,CarinaChenAsia-BOSLI=NoptoelectronicsSciamp;TechGroupCO.,LIMITEDFactoryADD:TaiHeRongIndustrialBldgA=LiaoKeng.Shiyan,Shenzhen(518108) OfficeA=DD:Room722,Building523,BaGuaLingIndustrialpark,BaGuaThirdRd,F=utiandistrict,shenzhenChina Mobile:+86-1536168098=0Fax:+86-755-23007107 SkypeID:Simaoled30E-mail:car...@simaoled.com =Website:www.simaoled.com Tounsubscribe,pleas=eclickhere
RE: Spam
Same here, only 1-2 messages per week, and generally correctly tagged as [SPAM]. Way less than the last discussion on this topic produced :) From: Kobus Bensch [mailto:kobus.ben...@trustpayglobal.com] Sent: vineri, 19 iunie 2015 12:06 To: haproxy@formilux.org Subject: Re: Spam I dont get any. On 19/06/2015 07:38, Roger Sikorski wrote: Hello, It is possibly to stop the spam which arrives here in the mailing list often? Greetings Roger Roger Sikorski Auszubildender Fachinformatiker Systemintegration RR Ice Cream Deutschland GmbH Eduard Pestel Str. 15 49080 Osnabrück Fax: +49 541 301 http://www.rr-icecream.eu/ www.rr-icecream.eu roger.sikor...@de.rr-icecream.eu mailto:roger.sikor...@de.rr-icecream.eu Handelsregister Amtsgericht Osnabrück HRB 17067 Sitz der Gesellschaft: Osnabrück Ident Nr. DE 117657534 Geschäftsführer: Dr. Ibrahim Najafi, Dr. Gotthard Kirchner P Before you print think about the ENVIRONMENT This e-mail has been scanned for viruses by RR Ice Cream. The service is powered by MessageLabs. -- Kobus Bensch Senior Systems Administrator Address: 22 24 | Frederick Sanger Road | Guildford | Surrey | GU2 7YD DDI: 0207 871 3958 Tel: 0207 871 3890 Email: kobus.ben...@trustpayglobal.com mailto:kobus.ben...@trustpayglobal.com Trustpay Global Limited is an authorised Electronic Money Institution regulated by the Financial Conduct Authority registration number 900043. Company No 07427913 Registered in England and Wales with registered address 130 Wood Street, London, EC2V 6DL, United Kingdom. For further details please visit our website at www.trustpayglobal.com http://www.trustpayglobal.com . The information in this email and any attachments are confidential and remain the property of Trustpay Global Ltd unless agreed by contract. It is intended solely for the person to whom or the entity to which it is addressed. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. Trustpay Global Ltd does not accept any liability for any personal view expressed in this message.
Re: Spam
I dont get any. On 19/06/2015 07:38, Roger Sikorski wrote: Hello, It is possibly to stop the spam which arrives here in the mailing list often? Greetings Roger *Roger Sikorski* *Auszubildender Fachinformatiker Systemintegration* RR Ice Cream Deutschland GmbH Eduard Pestel Str. 15 49080 Osnabrück * Fax: +49 541 301 *** www.rr-icecream.eu http://www.rr-icecream.eu/ roger.sikor...@de.rr-icecream.eu mailto:roger.sikor...@de.rr-icecream.eu Handelsregister Amtsgericht Osnabrück HRB 17067 Sitz der Gesellschaft: Osnabrück Ident Nr. DE 117657534 Geschäftsführer: Dr. Ibrahim Najafi, Dr. Gotthard Kirchner P*Before you print*think about the *ENVIRONMENT* This e-mail has been scanned for viruses by RR Ice Cream. The service is powered by MessageLabs. -- Kobus Bensch Trustpay Global LTD email signature Kobus Bensch Senior Systems Administrator Address: 22 24 | Frederick Sanger Road | Guildford | Surrey | GU2 7YD DDI: 0207 871 3958 Tel: 0207 871 3890 Email: kobus.ben...@trustpayglobal.com mailto:kobus.ben...@trustpayglobal.com -- Trustpay Global Limited is an authorised Electronic Money Institution regulated by the Financial Conduct Authority registration number 900043. Company No 07427913 Registered in England and Wales with registered address 130 Wood Street, London, EC2V 6DL, United Kingdom. For further details please visit our website at www.trustpayglobal.com. The information in this email and any attachments are confidential and remain the property of Trustpay Global Ltd unless agreed by contract. It is intended solely for the person to whom or the entity to which it is addressed. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. Trustpay Global Ltd does not accept any liability for any personal view expressed in this message.
Re: Spam
Well, there are around 20 a day I guess. It depends on the spamfilter you probably have set up on the mailserver you use to read the haproxy mailing list. They are mostly tagged right, but sometimes there is a false positive, so I don't think it's a good idea to filter them automatically. On vr, 2015-06-19 at 12:08 +0300, Andrei Marinescu wrote: Same here, only 1-2 messages per week, and generally correctly tagged as [SPAM]. Way less than the last discussion on this topic produced J From: Kobus Bensch [mailto:kobus.ben...@trustpayglobal.com] Sent: vineri, 19 iunie 2015 12:06 To: haproxy@formilux.org Subject: Re: Spam I dont get any. On 19/06/2015 07:38, Roger Sikorski wrote: Hello, It is possibly to stop the spam which arrives here in the mailing list often? Greetings Roger Roger Sikorski Auszubildender Fachinformatiker Systemintegration RR Ice Cream Deutschland GmbH Eduard Pestel Str. 15 49080 Osnabrück Fax: +49 541 301 www.rr-icecream.eu roger.sikor...@de.rr-icecream.eu Handelsregister Amtsgericht Osnabrück HRB 17067 Sitz der Gesellschaft: Osnabrück Ident Nr. DE 117657534 Geschäftsführer: Dr. Ibrahim Najafi, Dr. Gotthard Kirchner P Before you print think about the ENVIRONMENT This e-mail has been scanned for viruses by RR Ice Cream. The service is powered by MessageLabs. -- Kobus Bensch Senior Systems Administrator Address: 22 24 | Frederick Sanger Road | Guildford | Surrey | GU2 7YD DDI: 0207 871 3958 Tel: 0207 871 3890 Email: kobus.ben...@trustpayglobal.com Trustpay Global Limited is an authorised Electronic Money Institution regulated by the Financial Conduct Authority registration number 900043. Company No 07427913 Registered in England and Wales with registered address 130 Wood Street, London, EC2V 6DL, United Kingdom. For further details please visit our website at www.trustpayglobal.com. The information in this email and any attachments are confidential and remain the property of Trustpay Global Ltd unless agreed by contract. It is intended solely for the person to whom or the entity to which it is addressed. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. Trustpay Global Ltd does not accept any liability for any personal view expressed in this message.
Re: [ANNOUNCE] haproxy-1.6-dev2
Wow, sounds great, hope it comes soon :)
Bests,
-Igor
On Fri, Jun 19, 2015 at 8:00 PM, Willy Tarreau wi...@haproxy.com wrote:
On Fri, Jun 19, 2015 at 07:35:49PM +0800, Igor wrote:
It's very cool to have DNS finally! I wonder is that possible to do this
like?
use_backend us_upstream if {
hdr(Host),dnsname_to_ip_and_map(geo_us.lst) -m str us }
Convert hostname to IP, find IP's geo info, use matched backend.
Not yet. Maybe later it will be possible but for now the resolution is only
applied to checked servers.
Willy
Re: Question regarding haproxy nagios setup
2011-05-03 0:23 GMT+02:00 Amol mandm_z...@yahoo.com:
I was using the nagios plugin for haproxy
http://cvs.orion.education.fr/viewvc/viewvc.cgi/nagios-plugins-perl/trunk/plugins/check_haproxy.pl?revision=135view=markup
my nagios installation version is Nagios Core 3.2.0
in my host config i have declared the service as
define service {
usedefault-service
host_name server1
service_description HAProxy
check_command check_haproxy!
http://url/admin?stats;csv'!user!pass
servicegroups linux
}
and my checkcommand.cfg is
# command 'check_haproxy health'
define command {
command_name check_haproxy
command_line perl /etc/nagios3/libexec/check_haproxy.pl -u
$ARG1$ -U $ARG2$ -P $ARG3$
}
i have copied the check_haproxy.pl from my download folder to the path
mentioned in the checkcommand
on my nagios admin console i see
Current Status: CRITICAL (for 0d 1h 4m 44s)
Status Information:(null)
Performance Data:
and an alert is sent to my email even though the load balancing is working
fine,
i am able to run the command from the command line
perl /etc/nagios3/libexec/check_haproxy.pl -u 'http://url/ain?stats;csv'
-U user -P pass
HAPROXY OK - din_https (Active: 2/2) wbclus (Active: 2/2) |
t=0.135153s;2;10;0; sess_din_https=0sessions;;;0;2000
sess_wbclus=0sessions;;;0;2000
please let me know if i am missing something
Hello,
Maybe you should look at this version :
https://github.com/polymorf/check_haproxy
Regards
Joris
Re: Question regarding haproxy nagios setup
On 2015-06-19 16:08, Mauricio Aguilera wrote: El problema es por el ; antes del csv de la url Tengo el mismo problema y pude detectar que Nagios corta ahí el comando y obviamente se ejecuta mal, intenté pasarle los valores con y ' ', pero nada... Se les ocurre algo? Me gustaría tratar de hacer esta pregunta de nuevo en Inglés. Dado que la mayoría de la población mundial no habla español.
Re: Rate limiting on part of the URL path
Hi Bjoern,
I got a config working. This allows for the tracking and blocking of
requests matching a certain pattern in the path without consideration for
where the request comes from.
Thanks for your assistance, below is the config.
global
daemon
maxconn 10
defaults
mode http
timeout client 60s
timeout connect 5s
timeout server 60s
frontend HTTP
bind *:80
acl abc_present path_reg ^.*/(abc.*)/.*
http-request set-header X-Custom-ABC %[path] if abc_present
http-request replace-value X-Custom-ABC ^.*/(abc.*)/.* \1 if abc_present
stick-table type string size 1m expire 60m store gpc0,http_req_rate(60s)
acl hap-test_front hdr_reg(host) -i haproxytest.domain.tld
haproxytest3.domain.tld
use_backend HAPTEST if hap-test_front
backend HAPTEST
option httpchk GET /healthcheck HTTP/1.0
http-check expect status 200
tcp-request content track-sc0 hdr(X-Custom-ABC) table HTTP
acl too_fast sc0_http_req_rate(HTTP) ge 10
acl mark_too_fast sc0_inc_gpc0(HTTP) ge 0
http-request deny if too_fast mark_too_fast
server web web:80 check inter 5000 fastinter 1000 fall 1
--
Pierre
On Fri, Jun 19, 2015 at 9:11 AM, bjun...@gmail.com bjun...@gmail.com
wrote:
Ok, please try this:
http://blog.haproxy.com/2012/10/16/high-performance-waf-platform-with-naxsi-and-haproxy/
--
Bjoern
2015-06-19 15:04 GMT+02:00 Pierre Beaumier pie...@kkdzo.org:
Hi,
I actually am able to insert the string in the table and increase the
http_req_rate:
# table: HTTP, type: string, size:1048576, used:2
0x188193c: key=abc123 use=0 exp=3574082 http_req_rate(6)=4
0x1896f6c: key=abc_567 use=0 exp=3596948 http_req_rate(6)=17
My problem is that connections or requests should be refused if
http_req_rate is greater or equal to 10 however as you can see the rate
for
abc_567 is 17 and the requests were still handled.
--
Pierre
On Fri, Jun 19, 2015 at 8:51 AM, bjun...@gmail.com bjun...@gmail.com
wrote:
Hi,
if i understand you correctly, this is the same problem i was having:
http://godevops.net/2015/04/23/haproxy-tracking-multiple-sample-fetches-in-stick-table/
http://marc.info/?t=14082871045r=1w=2
--
Bjoern
2015-06-19 14:37 GMT+02:00 Pierre Beaumier pie...@kkdzo.org:
Hi Bjoern,
I was able to extract the information I need and put it in a table by
creating a custom header from the path and applying some regex but now
I'm
not sure how to actually rate limit based on that.
Here's a trimmed down version of my config.
global
daemon
maxconn 10
defaults
mode http
timeout client 60s
timeout connect 5s
timeout server 60s
frontend HTTP
bind *:80
tcp-request inspect-delay 2s
http-request deny if { sc0_http_req_rate ge 10 }
http-request set-header X-Custom-ABC %[path]
http-request replace-value X-Custom-ABC ^.*(abc.*)/.* \1
stick-table type string size 1m expire 60m store http_req_rate(60s)
acl hap-test_front hdr_reg(host) -i haproxytest.domain.tld
haproxytest3.domain.tld
use_backend HAPTEST if hap-test_front
backend HAPTEST
option httpchk GET /healthcheck HTTP/1.0
http-check expect status 200
tcp-request content track-sc0 hdr(X-Custom-ABC) table HTTP
server web web:80 check inter 5000 fastinter 1000 fall 1
I expected the http-request deny if { sc0_http_req_rate ge 10 }
stanza
to
refuse the request however the requests are still getting through and
the
counter still increases:
# table: HTTP, type: string, size:1048576, used:2
0x188193c: key=abc123 use=0 exp=3574082 http_req_rate(6)=4
0x1896f6c: key=abc_567 use=0 exp=3596948 http_req_rate(6)=17
Thanks
--
Pierre
On Thu, Jun 18, 2015 at 11:42 AM, bjun...@gmail.com
bjun...@gmail.com
wrote:
2015-06-17 15:00 GMT+02:00 Pierre Beaumier pie...@kkdzo.org:
Hello,
I'm using haproxy 1.5.12 and I'm trying to do rate limiting based
on
a
part
of a URL requested.
Requests I want to track and limit have the following form:
https://host1.domain.tld/field1/field2/morestuff?query……
- field1 is a word like user or data, there are 2 to 4 of them
and
they're known to me.
- field2 is what I really want to track, it's formed of 3 letters
that
never
change and followed by several characters including lower and upper
case
letters, numbers, dashes (-) and underscores (_). The field length
is
not
fixed however it will always be in second position in the path.
Examples
for
this field are abc_PT4gWk-42, abc1234 or abc-vb8WQ_2
My goal is have a table storing these with a counter for each,
block
if
we
get more than 10 per second and return an error message like too
many
requests. I'd like to be able to query this table to have an idea
of
the
abusers, this should be trivial by parsing the output of show
table.
I
votre bague à prix canon
Cet email a pour destinataire haproxy@formilux.org Je ne souhaite plus recevoir d'offre promotionnel Histoire d'Or 1er bijoutier de France BIJOUX MONTRES IDÉES CADEAUX cliquez ci-dessous pour recevoir les offres Histoire d'Or et profiter de nombreux avantages TROUVEZ LA BAGUE IDÉALE ! Faites votre choix ! JE DÉCOUVRE ! SOLITAIRE ARGENT 49€En cliquant ici, j'accepte de recevoir des offres commerciales de la part d'Histoire d'Or BAGUE OR ET TOPAZE 139 € SOLITAIRE ET OR BLANC 149 € BAGUE OR BLANC 149 € BAGUE OR ET DIAMANT 129 € Retrait sous 2H en magasin Livraison gratuite à partir de 49€ 30 jours pour changer d'avis Paiement 100% sécuriséNos conseillers au 09 69 32 36 19 Une offre qualitative, compétitive, créative, constamment renouvelée Des matériaux nobles : Or 375/1000ème, Or 750/1000ème, argent 925/1000ème, Pierres précieuses... Un certificat d'authenticité et une facture sont délivrés pour tout achat Des facilités de paiement : un paiement en 3 fois sans frais ou en 5, 10 ou 20 fois Une carte fidélité très avantageuse Une garantie de 2 ans sur tous nos bijoux et montres Des ateliers de professionnels spécialisés pour créer, transformer, réparer les bijoux mais aussi experts en gravure, polissage, sertissage, mise à taille, enfilage de perles ... Je ne souhaite plus recevoir d'offre promotionnel
[SPAM] New patent IP65 3W PIR LED Solar wall light
Dear Purchasing Manager Nice Day! I am Lancy from NEO LED Lights Co., Limited. Here is the good news! We have developed one solar led wall light. Main features: 1. Patented Design.2. Solar panel performs as Battery Charger - save 100% electric energy.3. PIR Sensor and Optically Controlled lamp. 4. Outdoor use - IP65 Waterproof Design.5. PMMA LGP - very soft and uniform light, no dark zone.6. 3 years guarantee. 7. Removable. Specification: Watt: 3W Power: 1.6W Solar Panel LED: Epistar SMD3014 CCT: WW NW CW Lumen: 200-300LM Beam angle: 120 degrees IP: 65 Size:180*125*30mm MOQ: 5PCS Dear friend, we sincerely hope can work together and make bigger market with you. By the way, if you have any need for other products, please contact me. Sincerely Lancy NEO LED Lights Co., Limited Sales Manager: Lancy Zeng Mob: 8615919798719 Tel: 86-755-23003620 Fax: 86-755-23701623
Re: Lua testcase.. some 'random' data returned when loading a image.. 1.6dev2
Ok changed the the lua implementation a little, still seeing 'different' images/colors appear when requesting the page repeatedly with a single browser though.. Assuming the 'penguinsimage' content doesnt change nor move in memory,, i suspect that somehow the txn.res:send is somehow subject to random buffer content overwriting.. function myinit(txn) local f = io.open(/var/etc/haproxy/Penguins.jpg, rb) penguinsimage = f:read(*all) f:close() end core.register_init(myinit) function hello_world(txn) txn.res:send(penguinsimage) txn:close() end Thierry FOURNIER schreef op 19-6-2015 om 14:22: On Fri, 19 Jun 2015 02:05:50 +0200 PiBa-NL piba.nl@gmail.com wrote: Hi guys, I'm sure i am abusing lua for completely wrong thing here. But i do not understand why the result isn't at least consistent.. Ive got a Pinguïns.jpg of 759kB (Default Windows 7 example image).. And have the configuration listed below. When requesting the image from a browser the top of the image looks normal, but further down it starts morphing, or becomes complete garbage.. Increasing bufsize to 30 makes the image show normal when reading and writing the whole image in 1 variable.. Though the buffer is still less than half of the image size.?. What im wondering though is how can it be that the results with smaller bufsizes vary..?? Is it overflowing some memory? With 1.6dev1 it would crash after a few requests, dev2 seems to have fixed that.. Though the random behavior is still strange.. I would expect every time the same image is send it to be cut short at buffsize, or perhaps just work if lua might use its own memory buffers not limited to haproxy's buffsize? Is it a bug? Or just a wrong lua script? Should files / sockets be closed by the script? I get an error if i do..(attempt to use a closed file) Hi, thank you for the repport. I'm currently trying to reproduce it, I'm not finished. I see two errors in your code: First, io.* are real blocking functions. HAProxy is really blocked waiting for the data access. It is a very bad to use it. However, how that you write for the file acces should work. Second, your variable f is not declared as local. This variable is keep between two requests. Maybe is the reason of your problem. To serve static file with Lua, the best practice is loading the full file during the initialisation and store it into a global variable. During the runtime, you will use only the variable and not the file. Thierry global #tune.bufsize 30 tune.lua.session-timeout 10 tune.lua.task-timeout 10 lua-load /var/etc/haproxy/hello_world.lua listen proxy bind :10001 tcp-request content lua hello_image function hello_image(txn) txn.res:send(HTTP/1.1 200 OK\n\n) f = io.open(/var/etc/haproxy/Penguins.jpg, rb) local block = 5000 while true do local bytes = f:read(block) if not bytes then break end txn.res:send(bytes) --core.msleep(25); ## changes behavior to be somewhat more succesfull.. end txn:close() --f:close() ## [ALERT] 168/232309 (74397) : Lua function 'hello_image': runtime error: /var/etc/haproxy/hello_world.lua:8: attempt to use a closed file. end root@OPNsense:/usr/ports/net/haproxy-devel # haproxy -vv HA-Proxy version 1.6-dev2-ad90f0d 2015/06/17 Copyright 2000-2015 Willy Tarreau wi...@haproxy.org Build options : TARGET = freebsd CPU = generic CC = cc CFLAGS = -O2 -pipe -fstack-protector -fno-strict-aliasing -DFREEBSD_PORTS OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_OPENSSL=1 USE_STATIC_PCRE=1 USE_PCRE_JIT=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built with zlib version : 1.2.8 Compression algorithms supported : identity(identity), deflate(deflate), raw-deflate(deflate), gzip(gzip) Built with OpenSSL version : OpenSSL 1.0.2b 11 Jun 2015 Running on OpenSSL version : OpenSSL 1.0.2b 11 Jun 2015 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes Built with PCRE version : 8.35 2014-04-04 PCRE library supports JIT : yes Built with Lua version : Lua 5.3.0 Built with transparent proxy support using: IP_BINDANY IPV6_BINDANY Available polling systems : kqueue : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 3 (3 usable), will use kqueue.
Re: Lua testcase.. some 'random' data returned when loading a image.. 1.6dev2
On Fri, 19 Jun 2015 20:35:50 +0200 PiBa-NL piba.nl@gmail.com wrote: Ok changed the the lua implementation a little, still seeing 'different' images/colors appear when requesting the page repeatedly with a single browser though.. Assuming the 'penguinsimage' content doesnt change nor move in memory,, i suspect that somehow the txn.res:send is somehow subject to random buffer content overwriting.. function myinit(txn) local f = io.open(/var/etc/haproxy/Penguins.jpg, rb) penguinsimage = f:read(*all) f:close() end core.register_init(myinit) function hello_world(txn) txn.res:send(penguinsimage) txn:close() end I reproduce the problem. I see an object with missing data when I send more than one connections. I currently looking for a solution. Thierry Thierry FOURNIER schreef op 19-6-2015 om 14:22: On Fri, 19 Jun 2015 02:05:50 +0200 PiBa-NL piba.nl@gmail.com wrote: Hi guys, I'm sure i am abusing lua for completely wrong thing here. But i do not understand why the result isn't at least consistent.. Ive got a Pinguïns.jpg of 759kB (Default Windows 7 example image).. And have the configuration listed below. When requesting the image from a browser the top of the image looks normal, but further down it starts morphing, or becomes complete garbage.. Increasing bufsize to 30 makes the image show normal when reading and writing the whole image in 1 variable.. Though the buffer is still less than half of the image size.?. What im wondering though is how can it be that the results with smaller bufsizes vary..?? Is it overflowing some memory? With 1.6dev1 it would crash after a few requests, dev2 seems to have fixed that.. Though the random behavior is still strange.. I would expect every time the same image is send it to be cut short at buffsize, or perhaps just work if lua might use its own memory buffers not limited to haproxy's buffsize? Is it a bug? Or just a wrong lua script? Should files / sockets be closed by the script? I get an error if i do..(attempt to use a closed file) Hi, thank you for the repport. I'm currently trying to reproduce it, I'm not finished. I see two errors in your code: First, io.* are real blocking functions. HAProxy is really blocked waiting for the data access. It is a very bad to use it. However, how that you write for the file acces should work. Second, your variable f is not declared as local. This variable is keep between two requests. Maybe is the reason of your problem. To serve static file with Lua, the best practice is loading the full file during the initialisation and store it into a global variable. During the runtime, you will use only the variable and not the file. Thierry global #tune.bufsize 30 tune.lua.session-timeout 10 tune.lua.task-timeout 10 lua-load /var/etc/haproxy/hello_world.lua listen proxy bind :10001 tcp-request content lua hello_image function hello_image(txn) txn.res:send(HTTP/1.1 200 OK\n\n) f = io.open(/var/etc/haproxy/Penguins.jpg, rb) local block = 5000 while true do local bytes = f:read(block) if not bytes then break end txn.res:send(bytes) --core.msleep(25); ## changes behavior to be somewhat more succesfull.. end txn:close() --f:close() ## [ALERT] 168/232309 (74397) : Lua function 'hello_image': runtime error: /var/etc/haproxy/hello_world.lua:8: attempt to use a closed file. end root@OPNsense:/usr/ports/net/haproxy-devel # haproxy -vv HA-Proxy version 1.6-dev2-ad90f0d 2015/06/17 Copyright 2000-2015 Willy Tarreau wi...@haproxy.org Build options : TARGET = freebsd CPU = generic CC = cc CFLAGS = -O2 -pipe -fstack-protector -fno-strict-aliasing -DFREEBSD_PORTS OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_OPENSSL=1 USE_STATIC_PCRE=1 USE_PCRE_JIT=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built with zlib version : 1.2.8 Compression algorithms supported : identity(identity), deflate(deflate), raw-deflate(deflate), gzip(gzip) Built with OpenSSL version : OpenSSL 1.0.2b 11 Jun 2015 Running on OpenSSL version : OpenSSL 1.0.2b 11 Jun 2015 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes Built with PCRE version : 8.35 2014-04-04 PCRE library supports JIT : yes Built with Lua version : Lua 5.3.0 Built with transparent proxy support using: IP_BINDANY IPV6_BINDANY Available polling systems : kqueue : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result
