Lots of spam on this list
Hello, Am I the only one to be amazed by the impressive amount of spam going through this mailing-list ? I know it's very difficult to fight against it, but I'm surprised to receive so many unsolicited mails on this one. Maybe moving to a google groups list ? signature.asc Description: OpenPGP digital signature
Re: Lots of spam on this list
Hello, 2014-09-18 10:18 GMT+02:00 Hoggins! fucks...@wheres5.com: I know it's very difficult to fight against it, but I'm surprised to receive so many unsolicited mails on this one. Maybe moving to a google groups list ? This has been already discussed a few days ago : http://marc.info/?l=haproxym=140979555128144w=2 Olivier
Re: Lots of spam on this list
Hello, Le 18/09/2014 10:28, Olivier a écrit : Hello, 2014-09-18 10:18 GMT+02:00 Hoggins! fucks...@wheres5.com mailto:fucks...@wheres5.com: I know it's very difficult to fight against it, but I'm surprised to receive so many unsolicited mails on this one. Maybe moving to a google groups list ? This has been already discussed a few days ago : http://marc.info/?l=haproxym=140979555128144w=2 Olivier Thank you Olivier, I joined a couple of days ago, so I couldn't be part of this discussion. I'll let you guys handle this. signature.asc Description: OpenPGP digital signature
haproxy sending RSTs to backend-servers
Hi, I’ve configured nginx+haproxy in front of a couple of IIS servers. NGINX terminates SSL. configuration is as following: global log /var/run/log local5 log /var/run/log local1 notice #log loghostlocal0 info maxconn 4096 #debug #quiet user www group www daemon defaults log global modehttp retries 2 timeout client 50s timeout connect 5s timeout server 50s option dontlognull option forwardfor option httplog option redispatch balance leastconn http-check expect string server_up http-check disable-on-404 default-server minconn 50 maxconn 100 # Set up application listeners here. frontend app-main-prod mode http bind 0.0.0.0:8000 maxconn 2000 default_backend app-main-prod-back frontend app-import mode http bind 0.0.0.0:8001 maxconn 2000 default_backend app-import-back frontend app-images mode http bind 0.0.0.0:8002 maxconn 2000 default_backend app-images-back backend app-main-prod-back balance leastconn fullconn 2000 mode http option httpchk GET /healthcheck.aspx HTTP/1.1\r\nHost:\ www.app.ch\r\nConnection:\ close cookie SERVERID insert indirect nocache server appsrv-one 192.168.69.17:80 weight 1 maxconn 1000 check cookie s1 server appsrv-two 192.168.69.18:80 weight 1 maxconn 1000 check cookie s2 backend app-import-back balance leastconn fullconn 2000 mode http #option httpchk GET /healthcheck.aspx HTTP/1.1\r\nHost:\ import.app.ch\r\nConnection:\ close server appsrv-import-one 192.168.69.32:80 weight 1 maxconn 1000 check #server appsrv-import-two 192.168.69.33:80 weight 1 maxconn 1000 check backend app-images-back balance leastconn fullconn 2000 mode http option httpchk GET /healthcheck.aspx HTTP/1.1\r\nHost:\ images.app.ch\r\nConnection:\ close server appsrv-images-one 192.168.69.41:80 weight 1 maxconn 1000 check #server appsrv-images-two 192.168.69.42:80 weight 1 maxconn 1000 check listen admin 0.0.0.0:22002 mode http stats uri / What happens is that it will mostly work, but in wireshark, I see a lot of RST being sent from the haproxy-server to the backend IIS-servers. This doesn’t make sense and is probably the reason I see so many 50x in the logs and why occasionally gateway-errors are being shown to users because nginx can’t find any live servers… Can anyone see any obvious error in the config?
Re: haproxy sending RSTs to backend-servers
On Thu, Sep 18, 2014 at 10:50 AM, Rainer Duffner rai...@ultra-secure.de wrote: Hi, I've configured nginx+haproxy in front of a couple of IIS servers. NGINX terminates SSL. configuration is as following: global log /var/run/log local5 log /var/run/log local1 notice #log loghostlocal0 info maxconn 4096 #debug #quiet user www group www daemon defaults log global modehttp retries 2 timeout client 50s timeout connect 5s timeout server 50s option dontlognull option forwardfor option httplog option redispatch balance leastconn http-check expect string server_up http-check disable-on-404 default-server minconn 50 maxconn 100 # Set up application listeners here. frontend app-main-prod mode http bind 0.0.0.0:8000 maxconn 2000 default_backend app-main-prod-back frontend app-import mode http bind 0.0.0.0:8001 maxconn 2000 default_backend app-import-back frontend app-images mode http bind 0.0.0.0:8002 maxconn 2000 default_backend app-images-back backend app-main-prod-back balance leastconn fullconn 2000 mode http option httpchk GET /healthcheck.aspx HTTP/1.1\r\nHost:\ www.app.ch\r\nConnection:\ close cookie SERVERID insert indirect nocache server appsrv-one 192.168.69.17:80 weight 1 maxconn 1000 check cookie s1 server appsrv-two 192.168.69.18:80 weight 1 maxconn 1000 check cookie s2 backend app-import-back balance leastconn fullconn 2000 mode http #option httpchk GET /healthcheck.aspx HTTP/1.1\r\nHost:\ import.app.ch\r\nConnection:\ close server appsrv-import-one 192.168.69.32:80 weight 1 maxconn 1000 check #server appsrv-import-two 192.168.69.33:80 weight 1 maxconn 1000 check backend app-images-back balance leastconn fullconn 2000 mode http option httpchk GET /healthcheck.aspx HTTP/1.1\r\nHost:\ images.app.ch\r\nConnection:\ close server appsrv-images-one 192.168.69.41:80 weight 1 maxconn 1000 check #server appsrv-images-two 192.168.69.42:80 weight 1 maxconn 1000 check listen admin 0.0.0.0:22002 mode http stats uri / What happens is that it will mostly work, but in wireshark, I see a lot of RST being sent from the haproxy-server to the backend IIS-servers. This doesn't make sense and is probably the reason I see so many 50x in the logs and why occasionally gateway-errors are being shown to users because nginx can't find any live servers... Can anyone see any obvious error in the config? Hi Rainer, HAProxy uses RST to close connections on the server side to allow fast reuse of the source port. So this behavior is expected and normal. That said, 50x errors are not normal... Can you tell us who is generating thoses errors? Can you share your HAProxy logs showing these errors? Baptiste
Re: Lots of spam on this list
You are seeing the amount of spam because some person has maliciously added the haproxy email address to these sites. There is not much that can be done about that as it is seen as legitimate email. Well mostly anyway. On 18/09/2014 09:18, Hoggins! wrote: Hello, Am I the only one to be amazed by the impressive amount of spam going through this mailing-list ? I know it's very difficult to fight against it, but I'm surprised to receive so many unsolicited mails on this one. Maybe moving to a google groups list ? -- 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.
PTC Users List
Hi, Would you be interested in PTC users list for your email and marketing campaign? We can provide you with Dassault systems, Siemens, Autodesk, Ansys and Bentley. We can also provide you with titles like, * Engineers, * Research and development * Project managers * Purchasing decision makers * CEO, CIO, CTO, CMO, CFO * Marketing Decision makers * Facility Managers * Fleet managers * Logistic Professionals Please let me know your thoughts on it Regards Michelle
Requests not expiring, exp=NEVER in Version: 1.5.3
Hi all, long time reader (less than a year), first time poster. We decided to update from Haproxy Version: 1.5-dev18 to Version: 1.5.3 and with the new machine with the new version we noticed many more current conns in the stats page. Typically with ~400 requests/s we would see ~800 current connections on the old version, but with the new version we saw upwards of 9000 current connections before we put traffic back to the old machine. Looking at stats show sess I noticed that many connections had age much larger than the timeout settings. The session details show connections with age= larger than the timeouts had show exp=NEVER . How does a connection get set to never expire? 0x12b9b20: proto=tcpv4 src=50.173.50.59:53192 fe=DefaultFrontEnd be= NONE srv=none ts=08 age=4m20s calls=2 rq[f=20h,i=0,an=1eh,rx=,wx=,ax=] rp[f=00h,i=0,an=00h,rx=,wx=,ax=] s0=[7,8h,fd=13,ex=] s1= [0,0h,fd=-1,ex=] exp= 0x12b9b20: [18/Sep/2014:15:11:33.591516] id=8 proto=tcpv4 source=50.173.50.59:53192 flags=0x80, conn_retries=0, srv_conn=(nil), pend_pos=(nil) frontend=DefaultFrontEnd (id=2 mode=http), listener=? (id=1) addr=10.162.174.207:80 backend=NONE (id=-1 mode=-) server=NONE (id=-1) task=0x12b9e90 (state=0x08 nice=0 calls=2 exp=NEVER age=56s) txn=0x12b9b68 flags=0x0 meth=0 status=-1 req.st=MSG_RQBEFORE rsp.st=MSG_RPBEFORE si[0]=0x12b9d70 (state=EST flags=0x08 endp0=CONN:0x12b99d0 exp= NEVER, et=0x000) si[1]=0x12b9da8 (state=INI flags=0x00 endp1=NONE:(nil) exp=NEVER, et=0x000) co0=0x12b99d0 ctrl=tcpv4 xprt=RAW data=STRM target=LISTENER:0x660 We had slightly different configs on each machine, but the issue still happened with the exact same config. Some of the config settings were depreciated like contimeout, clitimeout, srvtimeout and option httpclose so I replaced them with current timeout calls and option forceclose. I also tried using milliseconds and seconds for the timeouts which made no difference. I also tried turning http-server-close off and on but nothing resolved the long connections. I will post a washed version of the config that was working well on rev18 but having the issue on 1.5.3. #START CONFIG global maxconn 10 user haproxy group haproxy pidfile /var/run/haproxy.pid stats socket /tmp/haproxy level admin tune.maxrewrite 1024 defaults mode http maxconn 15000 balance roundrobin contimeout 4000 clitimeout 42000 srvtimeout 43000 stats enable stats refresh 30s stats auth XX:XX stats uri /haproxy?stats frontend DefaultFrontEnd bind :80 mode http option httpclose option forwardfor except 127.0.0.1 stick-table type string size 200k expire 10s store gpc0 log global log127.0.0.1 local0 log127.0.0.1 local7 debug option httplog option log-separate-errors acl whitelist src XXX.XXX.XXX.XXX tcp-request content reject if ! WAIT_END # tcp-request content reject if ! HTTP acl source_is_abuser sc1_get_gpc0 gt 0 acl API_dead nbsrv(API) lt 1 acl WWW-WithServerTimeout_dead nbsrv(WWW- WithServerTimeout) lt 1 acl WWW_dead nbsrv(WWW) lt 1 acl API-SANDBOX_dead nbsrv(API-SANDBOX) lt 1 acl BEAM_dead nbsrv(BEAM) lt 1 acl BEACON_dead nbsrv(BEACON) lt 1 acl validApiKey urlp(apiKey) -i -f /etc/haproxy/apikeys.lst acl beamMatch hdr_dom(host) -i XX.XX.com acl beaconMatch hdr_dom(host) -i XX.XX.com acl sandboxRateTooHigh be_sess_rate(API-SANDBOX) gt 25 acl sandboxConnTooHigh be_conn(API-SANDBOX) 10 acl sandboxMatch hdr_dom(host) -i XX.XX.com acl apiMatch hdr_dom(host) -i XX.XX.com acl apiMatch url_sub -i delivery/api acl uatMatch hdr_dom(host) -i XX.XX.com acl wwwMatch hdr_dom(host) -i XX.XX.com acl wwwMatch hdr_dom(host) -i XX.XX.com acl wwwMatch hdr_dom(host) -i XX.XX.com acl wwwMatch hdr_dom(host) -i XX.XX.com acl wwwMatch hdr_dom(host) -i XX.XX.com acl wwwMatch hdr_dom(host) -i XX.XX.com acl wwwMatch hdr_dom(host) -i XX.XX.com acl clickMatch url_sub -i _Click tcp-request content track-sc1 urlp(apiKey) if !source_is_abuser use_backend API-ABUSE if source_is_abuser apiMatch validApiKey use_backend YESMAN
change the size of a stick-table at run time
Hello, I want to change the size of a stick-table at run time, but I found no suitable management command in the docs. If I change the size in the config file, the stick-table gets flushed at reload, but I need to preserve its content. The only way I can think of at the moment is to dump the content manually before reload (show table) and refill it immediately afterwards (set table). But maybe there is a more elegant way...? Best regards, Tobi
Re: change the size of a stick-table at run time
Le 18 sept. 2014 21:43, Tobias Gunkel tobias.gun...@gmail.com a écrit : Hello, I want to change the size of a stick-table at run time, but I found no suitable management command in the docs. If I change the size in the config file, the stick-table gets flushed at reload, but I need to preserve its content. The only way I can think of at the moment is to dump the content manually before reload (show table) and refill it immediately afterwards (set table). But maybe there is a more elegant way...? Best regards, Tobi Hi tobi, Do you have a 'peer' section in haproxy's configuration file? Also, why don't you simply set up a stick table size big enough for your needs? Baptiste
Is Yacon Syrup for diabetics? 12.30 p m 12.9.2014]
haproxy@formilux.org Yacon syrup is a sugar substitute native to the Andean region of South America. The syrup is derived from the roots of the yacon plant, and according to some studies is a good source of antioxidants.Some studies have suggested that yacon syrup may be beneficial to the body in moderate amounts.The health benefits of yacon syrup have not been extensively tested, but information from the published studies suggests a mildly beneficial effect on the body. For diabetics, vegans and those cutting down on their sugar intake, yacon syrup makes a healthy alternative to synthesized sweeteners You can learn more about this product by visiting: http://yaconmolassesoffer.com/ To your health Bert healthy lifestyle applications click here To stop getting mails
Re: change the size of a stick-table at run time
On Thu, Sep 18, 2014 at 11:23 PM, Tobias Gunkel tobias.gun...@gmail.com wrote: Hi Baptiste, Do you have a 'peer' section in haproxy's configuration file? No. I thought this is for replicating stick-tables between remote servers, but I have only one server. But I'll have a look at the docs anyways, maybe this will fit my needs. Also, why don't you simply set up a stick table size big enough for your needs? I use stick-tables to limit access to a site based on the client ip address, independently from connection rate etc. So the size of the stick-table represents the pool of available slots to the site, which I eventually want to increase later at run time (if the server load allows it). -Tobi Hi Tobias, Please don't forget to Cc the ML, unless there are private information in your email. 'peer' section is also used to synchronize data between HAProxy processes, when HAProxy is reloaded. You should use it. create a 'peer' section and don't forget to use the 'peers' directive on the stick-table definition. concerning the stick-table size, you have acls which allows you to retrieve the number of entries in a table and so you can take allow or deny decision based on this. That said, you may have to reload HAProxy to update the number of entries the ACL should allow. Not sure there is a simple solution there. Baptiste
