[SPAM] Re: 2015 Super 5
Dear Super 5 Winner, The Super 5 is an E-LOTT program, under the supervision of MALTCO LOT LTD and the Super 5 numbers are randomly drawn from numbers 1 to 45 and each Super 5 Numbers are attached electronically to recipients email address and later entered in the Super 5 Random Electronic Program which eventually reveal the Winning Super 5 Numbers and the recipients email addresses. MALTCO LOT. Limited has a joint partnership with INTRALOT S.A, which makes them global front-runners in the design, development, operation, & support of integrated software and transaction processing systems. The company currently ranks third on revenues amongst integrated systems suppliers worldwide. Therefore, we the Management of the MALTCO LOT. LTD and INTRALOT S.A are gratified to inform you of a successful wins in the Super 5 Electronic Random E-LOT Program which was held 23rd Jan. 2015, and subsequently the Update came out 30th Jan. 2015, which your email address and the Super 5 Numbers 09 24 32 38 43 attached with your email address emerged as a Winning Email address and the Super 5 Numbers 09 24 32 38 43 winning the sum of €500,000.00 Euro, for these reasons we are obliged to inform you so that you can swiftly file for your claim. To proceed in filing for your claim, you are advice to contact our accredited Firm in charge of Authentication, Validation and Substantiation process. Below are the contact details of the officer in charge: Firm:PROSESA. S.A. Office Address: EDIFICIO EULEN, CTRA. DE LA CORUNA, KM. 18 - 28230 LAS ROZAS ESPANA. Officer in Charge: Dr. MARTENS J. HERNANDEZ. Contact Telephone: 0034 632 300 960. Email: info.prose...@yahoo.com Congratulations from MALTCO LOT. Limited and INTRALOT S.A. Sincerely, Mrs. Selena Heredia Moreno. Director of Public Relations of MALTCO LOT. Limited. Clique neste link para ser removido: http://frcmkt99.com.br/unsubscribe.php?M=2329902&C=e9233d4b4f5dd9a572f5f1ee14696b0a&L=23&N=31
BUG/MINOR: include/common/mini-clist.h: redefined symbol on FreeBSD
Hi -- Subject: HAProxy 1.5.10 and 1.5.11 redefine a symbol on FreeBSD 10.1 Index: src/ev_kqueue.c, include/common/mini-clist.h Synopsis: On FreeBSD 10.1 (probably also 10.0, and maybe earlier), a compiler warning is emitted because the macro LIST_PREV is redefined: % make TARGET=freebsd CC=gcc49 CPU_FLAGS= gcc49 -Iinclude -Iebtree -Wall -DDACS -DTPROXY -DCONFIG_HAP_CRYPT \ -DENABLE_POLL -DENABLE_KQUEUE -DUSE_OPENSSL -DUSE_PCRE -I/usr/local/include \ -DCONFIG_HAPROXY_VERSION=\"1.5.11\" -DCONFIG_HAPROXY_DATE=\"2015/01/31\" \ -c -o src/ev_kqueue.o src/ev_kqueue.c In file included from include/types/listener.h:33:0, from include/types/global.h:29, from src/ev_kqueue.c:26: include/common/mini-clist.h:147:0: warning: "LIST_PREV" redefined #define LIST_PREV(lh, pt, el) (LIST_ELEM((lh)->p, pt, el)) ^ In file included from /usr/include/sys/event.h:32:0, from src/ev_kqueue.c:17: /usr/include/sys/queue.h:461:0: note: this is the location of the previous definition #define LIST_PREV(elm, head, type, field)\ ^ Fix: This general issue seems to have already been seen with related macros for OpenBSD. At about line 52 of include/common/mini-clist.h, add: #undef LIST_PREV Perhaps the other LIST_* macros defined in mini-clist.h should also be explicitly undefined to avoid future naming conflicts. Thanks, Barry ** Barry Brachman, Ph.D. ** Distributed Systems Software, Inc. ** http://www.dss.ca ** Email: brach...@dss.ca | barry.brach...@gmail.com
Re: [PATCH/RFC 0/8] Email Alerts
On Tue, Feb 03, 2015 at 05:13:02PM +0100, Baptiste wrote: > On Tue, Feb 3, 2015 at 4:59 PM, Pavlos Parissis > wrote: > > On 01/02/2015 03:15 μμ, Willy Tarreau wrote: > >> Hi Simon, > >> > >> On Fri, Jan 30, 2015 at 11:22:52AM +0900, Simon Horman wrote: > >>> Hi Willy, Hi All, > >>> > >>> the purpose of this email is to solicit feedback on an implementation > >>> of email alerts for haproxy the design of which is based on a discussion > >>> in this forum some months ago. > > > > > > It would be great if we could use something like this > > acl low_capacity nbsrv(foo_backend) lt 2 > > mail alert if low_capacity > > > > In some environments you only care to wake up the on-call sysadmin if you > > are > > real troubles and not because 1-2 servers failed. > > > > Nice work, > > Pavlos > > > > > > This might be doable using monitor-uri and monitor fail directives in > a dedicated listen section which would fail if number of server in a > monitored farm goes below a threshold. > > That said, this is a dirty hack. A agree entirely that there is a lot to be said for providing a facility for alert suppression and escalation. To my mind the current implementation, which internally works with a queue, lends itself to these kinds of extensions. The key question in mind is how to design advanced such as the one you have suggested in such a way that they can be useful in a wide range of use-cases. So far there seem to be three semi-related ideas circulating on this list. I have added a fourth: 1. Suppressing alerts based on priority. e.g. Only send alerts for events whose priority is > x. 2. Combining alerts into a single message. e.g. If n alerts are queued up to be sent within time t then send them in one message rather than n. 3. Escalate alerts e.g. Only send alerts of priority x if more than n have occurred within time t. This seems to be a combination of 1 and 2. This may or not involve raising the priority of the resulting combined alert (internally or otherwise) An extra qualification may be that the events need to relate to something common: e.g. servers of the same proxy Loosing one may not be bad, loosing all of them I may wish to get out of bed for 4. Suppressing transient alerts e.g. I may not care if server s goes down then comes back up again within time t. But I may if it keeps happening. This part seems like a variant of 3. I expect we can grow this list of use-cases. I also think things may become quite complex quite quickly. But it would be nice to implement something not overly convoluted yet useful.
Possible bug with del acl
Below is my haproxy config file, the contents of both ACL files (Empty and we are only really using one in my example) as well as the steps I am taking to add and remove an ACL via the socket. It appears that after the removal of the ACL haproxy still behaves as if the ACL is still in place. - Start of haproxy config - #- # Global settings #- global # to have these messages end up in /var/log/haproxy.log you will # need to: # # 1) configure syslog to accept network log events. This is done #by adding the '-r' option to the SYSLOGD_OPTIONS in #/etc/sysconfig/syslog # # 2) configure local2 events to go to the /var/log/haproxy.log # file. A line like the following can be added to # /etc/sysconfig/syslog # #local2.* /var/log/haproxy.log # chroot /var/lib/haproxy-chroot pidfile /var/run/haproxy.pid maxconn 4000 userhaproxy group haproxy daemon tune.ssl.default-dh-param 1024 # turn on stats unix socket stats socket/var/run/haproxy.sock mode 600 level admin stats timeout 5s #- # common defaults that all the 'listen' and 'backend' sections will # use if not designated in their block #- defaults modehttp log global option dontlognull option forwardfor option http-server-close retries 3 timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s #- # stats web #- listen stats :8082 mode http stats enable stats uri / #- # frontends/backends below here #- frontend main *:8000 # ACLS acl bucket-none hdr(host) -i -f /etc/haproxy/acl.d/default.hosts.acl.conf acl bucket-main1-a hdr(host) -i -f /etc/haproxy/acl.d/main1-a.hosts.acl.conf # use backends based off ACL use_backend main0-aif bucket-none use_backend main1-aif bucket-main1-a backend main0-a server server-main0-a 127.0.0.1:9000 check backend main1-a server server-main1-a 127.0.0.1:9001 check - End of haproxy config - - Start of contents of default.hosts.acl.conf - - End of contents of default.hosts.acl.conf - - Start of contents of main1-a.hosts.acl.conf - - End of contents of main1-a.hosts.acl.conf - - start of confirmation that backends work - $ curl http://localhost:9000 0 $ curl http://localhost:9001 1 - end of confirmation that backends work - - Confirmation that frontend does not work before adding acl via socket - $ curl -H 'Host: test.com' http://localhost:8000 503 Service Unavailable No server is available to handle this request. - End confirmation that frontend does not work before adding acl via socket - - Adding of the test.com acl - $ echo "add acl /etc/haproxy/acl.d/default.hosts.acl.conf test.com" | socat /var/run/haproxy.sock stdio Done. - End adding of the test.com acl - - Confirmation that the ACL additon worked - $ curl -H 'Host: test.com' http://localhost:8000 0 - End confirmation that the ACL additon worked - - Deletion of ACL - $ echo "del acl /etc/haproxy/acl.d/default.hosts.acl.conf test.com" | socat /var/run/haproxy.sock stdio Done. - End deletion of ACL - - Start of Proof that for some reason haproxy behaves as if the acl still exists - $ curl -H 'Host: test.com' http://localhost:8000 0 - End of Proof that for some reason haproxy behaves as if the acl still exists - - Kevin
Re: HAproxy constant memory leak
Hi Georges-Etienne, On Tue, Feb 03, 2015 at 08:09:15AM -0500, Georges-Etienne Legendre wrote: > Hi Willy, > > Thanks a lot for this investigation, it was really helpful. > > My OpenSSL is up-to-date on this server. I first tried to remove the chroot > statement. I'm pretty sure this in itself solved the leak, but I no longer > have the traces and couple of hours after, our Ops changed the SSL check to > a simple TCP check on port 443. So, I cannot confirm 100%. > > I can however confirm that I no longer experience the leak. I put back the > chroot command to be safer. OK that's great. > This also prompted me to tweak the SSL ciphers. I now use a more thoughtful > list of ciphers ( > https://mozilla.github.io/server-side-tls/ssl-config-generator/) and > disabled SSLv3. This indeed disables KRB5. > > ssl-default-bind-ciphers > ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA > ssl-default-bind-options no-sslv3 Wow! When we introduced SSL, I expected that a lot of difficulties would come from it, but not that the ugliest config statements would come with it as well :-) > I will keep a close eye on the memory usage... HAproxy has been running for > about 16 hours now, and here is the ps output: > # ps -u nobody u > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > nobody 63985 0.5 0.0 53868 10960 ?Ss Feb02 5:19 > /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid > > Looks good :-) Yes indeed. Now I think it will really be important to report this leak to whomever it concerns (probably the distro vendor so that they decide whether it's in their own patches or in openssl upstream). My openssl version doesn't have krb5 and I have never understood what is needed to enable it nor what it provides. Crypto libs tend to be cryptic ... Willy
Re: [PATCH/RFC 0/8] Email Alerts
Hi Scott, On Tue, Feb 03, 2015 at 03:27:13PM +, Scott McKeown | redIT wrote: > Hi Willy, > > Can you please just confirm where this has been merged into as I've > downloaded the v1.6-dev0 archive today and I can't see it in there also > I've tried Horms github version at > https://github.com/horms/haproxy/tree/devel/email-alert which does look > to have all the options in but I can't test this on either the v1.5.11 > branch or v1.6-dev0 It's only in the git repo. We have not yet emitted a -dev version given that nothing really interesting (before this) was merged yet. And more importantly I'd like to fix the config parser *before* even dev1 so that users don't fear to upgrade from dev1 to any other one. I'm pretty sure however that Simon's patches will easily be backported to 1.5 without too much trouble if you're interested in using them on your local version. Regards, Willy
RE: haproxy 1.5 [ redirect scheme ssl custom port 5443 ]
> Summary: http:5000 to https:54443 with relative_uri as it is. (change > is in scheme and port number). Use redirect "prefix" [1] instead of scheme or location: redirect prefix https://mps-haproxy.int:5443 > I am using: HA-Proxy version 1.5-dev25-a339395 2014/05/10 I strongly suggest to upgrade to a stable release, btw. Lukas [1] http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#redirect
haproxy 1.5 [ redirect scheme ssl custom port 5443 ]
Hello,
*Summary*: http:5000 to https:54443 with relative_uri as it is. (change is
in scheme and port number).
Situation is when user hits:
"*http://*mps-haproxy.int:*5000*/internalapi/connectionstring";
haproxy redirects scheme but uses the same port of http i.e. "*https*://
mps-haproxy.int:*5000*/internalapi/connectionstring"
*Question: I want to redirect scheme with ssl port which is 5443*. Could
you please let me know how can I do this (so my url becomes:
https://mps-haproxy.int:5443/internalapi/connectionstring)?
1. I did not find the way to set the custom port in "redirect scheme ..."
2. I did not find the way to set the reltive_uri dynamically in "redirect
location:. I want "redirect location
https://mps-haproxy.int:5443/"
- which end user expects when requested over non-ssl
*snip from haproxy.config:*
...
...
frontend http
bind *:*5000*
#redirect scheme https if !{ ssl_fc }
#redirect location https://mps-haproxy.int:5443
default_backend api
reqadd X-Scheme:\ http
frontend https
bind *:*5443* ssl crt /etc/haproxy/certs/ulti-cloud.pem
default_backend api
reqadd X-Scheme:\ https
...
...
I do not want user to redirect to ssl context root by default, if user is
requesting "http://mps-haproxy:5000/helps/index.html"; then ssl redirect
should go to "https://mps-haproxy:5443/helps/index.html"; - notice port is
different.
I am using: HA-Proxy version 1.5-dev25-a339395 2014/05/10
Thanks,
- raavi
RE: Option no-sslv3 no being honoured with wildcard certs
> Hi, > > Thanks for getting back to me, I found the issue - we are not using sslv3 > for obvious reasons but the ssl health check only uses v3 and thus >the check handshake was failing. > > My bad only noticed a little after, is there a plan to support TLS level > handshake ? Yes, use check (or check-ssl) [1] instead of ssl-hello-chk. Since I don't know your configuration, I'm not sure how exactly this needs to look like so that it applies to your configuration, but the important message is: ssl-hello-chk = static SSLv3 hello (no openssl support needed) check-ssl = a proper SSL/TLS session is established via openssl http://cbonte.github.io/haproxy-dconv/configuration-1.5.html&check-ssl
Re: [PATCH/RFC 0/8] Email Alerts
On Tue, Feb 3, 2015 at 4:59 PM, Pavlos Parissis wrote: > On 01/02/2015 03:15 μμ, Willy Tarreau wrote: >> Hi Simon, >> >> On Fri, Jan 30, 2015 at 11:22:52AM +0900, Simon Horman wrote: >>> Hi Willy, Hi All, >>> >>> the purpose of this email is to solicit feedback on an implementation >>> of email alerts for haproxy the design of which is based on a discussion >>> in this forum some months ago. > > > It would be great if we could use something like this > acl low_capacity nbsrv(foo_backend) lt 2 > mail alert if low_capacity > > In some environments you only care to wake up the on-call sysadmin if you are > real troubles and not because 1-2 servers failed. > > Nice work, > Pavlos > This might be doable using monitor-uri and monitor fail directives in a dedicated listen section which would fail if number of server in a monitored farm goes below a threshold. That said, this is a dirty hack. Baptiste
Re: [PATCH/RFC 0/8] Email Alerts
On 01/02/2015 03:15 μμ, Willy Tarreau wrote: > Hi Simon, > > On Fri, Jan 30, 2015 at 11:22:52AM +0900, Simon Horman wrote: >> Hi Willy, Hi All, >> >> the purpose of this email is to solicit feedback on an implementation >> of email alerts for haproxy the design of which is based on a discussion >> in this forum some months ago. It would be great if we could use something like this acl low_capacity nbsrv(foo_backend) lt 2 mail alert if low_capacity In some environments you only care to wake up the on-call sysadmin if you are real troubles and not because 1-2 servers failed. Nice work, Pavlos signature.asc Description: OpenPGP digital signature
RE: Option no-sslv3 no being honoured with wildcard certs
Hi, Thanks for getting back to me, I found the issue - we are not using sslv3 for obvious reasons but the ssl health check only uses v3 and thus the check handshake was failing. My bad only noticed a little after, is there a plan to support TLS level handshake ? Paul -Original Message- From: Lukas Tribus [mailto:luky...@hotmail.com] Sent: 30 January 2015 18:53 To: Paul Gilligan; haproxy@formilux.org Subject: RE: Option no-sslv3 no being honoured with wildcard certs > I have a situation where the no-sslv3 is being ignored using version > 1.5.10 on centos 6.6 and my test backend Java Rest api test servers > are rejecting SSL handshakes with : Please post you configuration, "haproxy -vv" output and a ssldump of the failed ssl handshake. This doesn't make any sense, because even without "no-sslv3" openssl would still negotiate TLS if the backend supports it. Lukas - The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information, or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Although this e-mail and any attachments are believed to be free of any virus, or other defect which might affect any computer or system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Moneysupermarket.com Financial Group Limited for any loss or damage from receipt or use thereof. The views expressed are of the individual, and do not necessarily reflect the views of Moneysupermarket.com Financial Group Limited. Moneysupermarket.com Limited is an appointed representative of Moneysupermarket.com Financial Group Limited, which is authorised and regulated by the Financial Services Authority (FSA FRN 303190). Moneysupermarket.com Financial Group Limited, registered in England No. 3157344. Registered Office: Moneysupermarket House, St. David’s Park, Ewloe, CH5 3UZ. Telephone 01244 665700.
Re: [PATCH/RFC 0/8] Email Alerts
Hi Willy, Can you please just confirm where this has been merged into as I've downloaded the v1.6-dev0 archive today and I can't see it in there also I've tried Horms github version at https://github.com/horms/haproxy/tree/devel/email-alert which does look to have all the options in but I can't test this on either the v1.5.11 branch or v1.6-dev0 Ta, Scott On 02/02/2015 23:40, Willy Tarreau wrote: So I've merged it now, all 8 patches. Now I trust you to provide the doc so that users can quickly start testing it. Do not hesitate either if you want to fix issues or change your mind about certain points you are not happy with, this is still in development, no worries! Thanks! Willy
Re: HAproxy constant memory leak
Hi Willy,
Thanks a lot for this investigation, it was really helpful.
My OpenSSL is up-to-date on this server. I first tried to remove the chroot
statement. I'm pretty sure this in itself solved the leak, but I no longer
have the traces and couple of hours after, our Ops changed the SSL check to
a simple TCP check on port 443. So, I cannot confirm 100%.
I can however confirm that I no longer experience the leak. I put back the
chroot command to be safer.
This also prompted me to tweak the SSL ciphers. I now use a more thoughtful
list of ciphers (
https://mozilla.github.io/server-side-tls/ssl-config-generator/) and
disabled SSLv3. This indeed disables KRB5.
ssl-default-bind-ciphers
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
ssl-default-bind-options no-sslv3
I will keep a close eye on the memory usage... HAproxy has been running for
about 16 hours now, and here is the ps output:
# ps -u nobody u
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
nobody 63985 0.5 0.0 53868 10960 ?Ss Feb02 5:19
/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid
Looks good :-)
-- Georges-Etienne
On Mon, Feb 2, 2015 at 10:25 AM, Willy Tarreau wrote:
> Georges-Etienne,
>
> your captures were extremely informative. While I cannot reproduce the
> behaviour here even by reinjecting the same health check requests, I'm
> seeing two really odd things in your trace below :
>
> We accept an SSL connection from the firewall :
>
> 08:15:52.297357 accept(6, {sa_family=AF_INET, sin_port=htons(32764),
> sin_addr=inet_addr("")}, [16]) = 1
>
> It sends 48 bytes :
>
> 08:15:52.297717 read(1, "\200.\1\3\0\0\25\0\0\0\20", 11) = 11
> 08:15:52.297831 read(1,
> "\0\0\3\0\0\10\0\0\6\4\0\200\0\0\4\0\0\5O\0\0@\202J#i\242K7)\300\2536o\245=\23",
> 37) = 37
>
> Then we're checking for /etc/krb5.conf :
>
> 08:15:52.297984 stat("/etc/krb5.conf", 0x7fff544b1990) = -1 ENOENT (No
> such file or directory)
>
> Then trying to read some random :
>
> 08:15:52.298082 open("/dev/urandom", O_RDONLY) = -1 ENOENT (No such file
> or directory)
>
> Then trying to figure the local host name :
>
> 08:15:52.298187 uname({sys="Linux", node="", ...})
> = 0
>
> Then doing some netlink-based studd :
>
> 08:15:52.298316 socket(PF_NETLINK, SOCK_RAW, 0) = 2
> 08:15:52.298395 bind(2, {sa_family=AF_NETLINK, pid=0, groups=},
> 12) = 0
> 08:15:52.298471 getsockname(2, {sa_family=AF_NETLINK, pid=9103,
> groups=}, [12]) = 0
> 08:15:52.298550 sendto(2, "\24\0\0\0\26\0\1\3\210x\317T\0\0\0\0\0\0\0\0",
> 20, 0, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20
> 08:15:52.298650 recvmsg(2, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
> groups=},
> msg_iov(1)=[{"0\0\0\0\24\0\2\0\210x\317T\217#\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1\10\0\2\0\177\0\0\1\7\0\3\0lo\0\0<\0\0\0\24\0\2\0\210x\317T\217#\0\0\2\32\200\0\n\0\0\0\10\0\1\0\n\0\35\22\10\0\2\0\n\0\35\22\10\0\4\0\n\0\35?\n\0\3\0bond0\0\0\0<\0\0\0\24\0\2\0\210x\317T\217#\0\0\2\32\200\0\f\0\0\0\10\0\1\0\n\2\177\217\10\0\2\0\n\2\177\217\10\0\4\0\n\2\177\277\n\0\3\0bond2\0\0\0<\0\0\0\24\0\2\0\210x\317T\217#\0\0\2\32\200\0\r\0\0\0\10\0\1\0\nZ\6j"...,
> 4096}], msg_controllen=0, msg_flags=0}, 0) = 356
> 08:15:52.298841 recvmsg(2, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
> groups=},
> msg_iov(1)=[{"@\0\0\0\24\0\2\0\210x\317T\217#\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\24\0\6\0\377\377\377\377\377\377\377\377H\3\0\0H\3\0\0@
> \0\0\0\24\0\2\0\210x\317T\217#\0\0\n@
> \200\375\n\0\0\0\24\0\1\0\376\200\0\0\0\0\0\0\3064k\377\376\256\37@
> \24\0\6\0\377\377\377\377\377\377\377\377f\5\0\0f\5\0\0@
> \0\0\0\24\0\2\0\210x\317T\217#\0\0\n@
> \200\375\v\0\0\0\24\0\1\0\376\200\0\0\0\0\0\0\3064k\377\376\256\37A\24\0\6\0\377\377\377\377\377\377\377\377\232\5\0\0\232\5\0\0@\0\0\0\24\0\2\0"...,
> 4096}], msg_controllen=0, msg_flags=0}, 0) = 448
> 08:15:52.299059 recvmsg(2, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
> groups=},
> msg_iov(1)=[{"\24\0\0\0\3\0\2\0\210x\317T\217#\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\24\0\6\0\377\377\377\377\377\377\377\377H\3\0\0H\3\0\0@
> \0\0\0\24\0\2\0\210x\317T\217#\0\0\n@
> \200\375\n\0\0\0\24\0\1\0\376\200\0\0\0\0\0\0\3064k\377\376\256\37@
> \24\0\6\0\377\377\377\377\377\377\377\377f\5\0\0f
Re: Global ACLs
Hi Willy, On 2015-02-02 17:31, Willy Tarreau wrote: Hi Christian, On Mon, Feb 02, 2015 at 04:55:56PM +0100, Christian Ruppert wrote: Hey, are there some kind of global ACLs perhaps? I think that could be really useful. In my case I have ~70 frontends and ~100 backends. I often use the same ACLs on multiple frontends/backends for specific whitelisting etc. It would be extremely helpful to specify some of those ACLs in the global scope and use it where needed without having to re-define it again and again. Technically that shouldn't be much different from what it does in the local scope, shouldn't it? So I guess the ACL is prepare once on startup, it shouldn't matter where that is done. Using it so actually evaluating it is always (as before) done in the local scope, depending on the actual Layer etc. So adding support for global ACLs should be easy and helpful, or am I wrong? Did I forgot something important here? Example: global acl foo src 192.168.1.1 acl foobar hdr_ip(X-Forwarded-For,-1) 192.168.1.2 # This *might* be a special case... Not yet further verified. frontend example use_backend ... if foo use_backend ... if foobar We've been considering this for a while now without any elegant solution. Recently while discussing with Emeric we got an idea to implement "scopes", and along these lines I think we could instead try to inherit ACLs from other frontends/backends/defaults sections. Currently defaults sections support having a name, though this name is not internally used, admins often put some notes there such as "tcp" or a customer's id. That would be perfect, even better than just global. One could use the same ACL names but in different scopes, i.e. different layer. Here we could have something like this : defaults foo acl local src 127.0.0.1 frontend bar acl client src 192.168.0.0/24 use_backend c1 if client use_backend c2 if foo/local It would also bring the extra benefit of allowing complex shared configs to use their own "global" ACLs regardless of what is being used in other sections. That's just an idea, of course. Yeah, that sounds pretty decent to me. Regards, Willy -- Regards, Christian Ruppert
Re: Help haproxy
2015-02-02 16:45 GMT+01:00 Sander Klein : The only other thing that I can think of is that your client is behind a > proxy server which adds the X-Forward-For header for you... > > Or you got something strange in your config... > > Sander > You're totally right. My client have a proxy server. I feel very sorry for this stupid mistake. Thanks for your time and your help. Regards, Mathieu
