Re: [PATCH] DOC: mention support for RFC 5077 TLS Ticket extension in starter guide
On Thu, Aug 27, 2015 at 02:58:51PM +0200, Pavlos Parissis wrote: ./haproxy-dconv.py -i ../haproxy/doc/intro.txt -o /tmp/haproxy-intro/intro.html Importing /home/pparissis/repo/haproxy/doc/intro.txt... Line `1358' exceeds 80 columns Parsing chapter ... Parsing chapter Summary... Parsing chapter Available documentation... Parsing chapter Quick introduction to load balancing and load balancers... Parsing chapter Introduction to HAProxy... Parsing chapter What HAProxy is and is not... Parsing chapter How HAProxy works... Parsing chapter Basic features... Parsing chapter Basic features : Proxying... Parsing chapter Basic features : SSL... Parsing chapter Basic features : Monitoring... Parsing chapter Basic features : High availability... Parsing chapter Basic features : Load balancing... Parsing chapter Basic features : Stickiness... Parsing chapter Basic features : Sampling and converting information... Parsing chapter Basic features : Maps... Parsing chapter Basic features : ACLs and conditions... Parsing chapter Basic features : Content switching... Parsing chapter Basic features : Stick-tables... Parsing chapter Basic features : Formated strings... Parsing chapter Basic features : HTTP rewriting and redirection... Parsing chapter Basic features : Server protection... Parsing chapter Basic features : Logging... Parsing chapter Basic features : Statistics... Parsing chapter Advanced features... Parsing chapter Advanced features : Management... Parsing chapter Advanced features : System-specific capabilities... Parsing chapter Advanced features : Scripting... Parsing chapter Sizing... Parsing chapter How to get HAProxy... Parsing chapter Companion products and alternatives... Parsing chapter Apache HTTP server... Parsing chapter NGINX... Parsing chapter Varnish... Parsing chapter Alternatives... Generating keywords links... Exporting to /tmp/haproxy-intro/intro.html... The attached file is the result. It doesn't look good as it misses some css. But, it spotted 1 line which exceeds the column limit. Well, the result is pretty good. Here I'm having the search box partially overlap with the text, probably due to a missing logo, but navigation links work fine and chapters as well. I've just fixed the too long line, thanks for this. Cheers, Willy
Re: [PATCH] DOC: mention support for RFC 5077 TLS Ticket extension in starter guide
Hi Pavlos,
On Tue, Aug 25, 2015 at 10:26:06PM +0200, Pavlos Parissis wrote:
On 25/08/2015 11:21 , Willy Tarreau wrote:
On Mon, Aug 24, 2015 at 01:43:54PM +0200, Pavlos Parissis wrote:
Hi,
Please consider applying the attached patch.
Applied, thank you Pavlos.
Willy
Thanks for this awesome(missing) document.
Thank you. My goal is to write management.txt to explain how to manage
the process (start/stop/reload/signals/dump/etc) and then remove entirely
the outdated haproxy-{en,fr} files.
BTW, will it be available in HTML format as the config guide?
Probably, the format is exactly the same so it should work fine with
Cyril's dconv utility. I've not tested and I know he's quite busy right
now so we'll probably have to wait a bit unless someone with spare time
wants to pass dconv over it to confirm it works fine or suggest changes :-)
Cheers,
Willy
Re: [PATCH] DOC: mention support for RFC 5077 TLS Ticket extension in starter guide
Hi all, - Mail original - De: Pavlos Parissis pavlos.paris...@gmail.com À: Willy Tarreau w...@1wt.eu Cc: haproxy@formilux.org Envoyé: Jeudi 27 Août 2015 14:58:51 Objet: Re: [PATCH] DOC: mention support for RFC 5077 TLS Ticket extension in starter guide On 27/08/2015 02:39 μμ, Willy Tarreau wrote: Hi Pavlos, On Tue, Aug 25, 2015 at 10:26:06PM +0200, Pavlos Parissis wrote: BTW, will it be available in HTML format as the config guide? Probably, the format is exactly the same so it should work fine with Cyril's dconv utility. I've not tested and I know he's quite busy right now so we'll probably have to wait a bit unless someone with spare time wants to pass dconv over it to confirm it works fine or suggest changes :-) I have already made some tests. I identified some required changes to fix the header part parsing (nothing really difficult). I think I'll find some time during the week-end for that. Apart from this small fix, everything looked good. Cheers, Cyril Bonté
[SPAM] High Brightness LED Bulb Accept Customization
Dear purchasingmanager, This is Hebei Xiangyang Optoelectronic Technology Co., Ltd specialized in LED Light for many years. Our products including LED Bulb, LED Street Light, LED Tube, LED Street Light, Tunnel Light, etc.We have our own technology personnel,we can make the light as your need,including the logo,packing,etc. If you are interested,pls contact us without any hesitation. Look forward to hearing from you soon. Sincerely, Monica, Company: Hebei Xiangyang Optoelectronic Technology Co., Ltd. Add:No.8 xingyuanNorth Road, Economic Development Zone,Luquan,Hebei,China. Chinese Web:http://www.xyled.net (This is the Chinese website,the English one is updating,thanks for your understanding ) Tel: +86-0311-85519816 Tel: +86-13832187632 Skype: hbxymonica Email:hbxymon...@yahoo.com hbxymon...@hotmail.com
Re: [PATCH] DOC: mention support for RFC 5077 TLS Ticket extension in starter guide
Hi Cyril! On Thu, Aug 27, 2015 at 03:16:08PM +0200, Cyril Bonté wrote: I have already made some tests. I identified some required changes to fix the header part parsing (nothing really difficult). I think I'll find some time during the week-end for that. Apart from this small fix, everything looked good. Great, that sounds good! I wanted to issue dev4 today but face another bug related to txn.close() which I want to discuss with Thierry (who's quite busy as well), so I'll probably wait for this week-end. If we end up with your changes that will start to look in good shape for a release expected in about one month now. Cheers, Willy
TCP_NODELAY in tcp mode
Hello, we have a client-server application which establish a long-living TCP connection and generates a lot of small request-response packets which need to be processed very fast. Setting TCP_NODELAY on sockets speed things up to about 3 times. Not I want to put a haproxy in the middle so it balances traffic between several servers. Something like defaults mode tcp frontend shard0-front bind *:9000 default_backend shard0-back backend shard0-back server srv1 srv1:3456 check server srv2 srv2:3456 check In such configuration application slows significantly. I suspect that setting frontend's and backend's sockets option TCP_NODELAY would help as it did without haproxy involved. Is there any parameter which allows me to set TCP_NODELAY option? Thanks!
Re: Easy haproxy redundancy
Yeah, keepalived handles the gratuitous arp on failover, it works nicely. I do miss the admin tools for pacemaker though. I'm AFK, but I'll write up a full explanation of our HA setup when I'm back at a PC. Cheers, Nathan On Thu, Aug 27, 2015, 6:11 PM Shawn Heisey hapr...@elyograg.org wrote: On 8/27/2015 6:52 PM, Nathan Williams wrote: There's a sysctl for that, net.ipv4.ip_nonlocal_bind. Interesting. That's one I had never seen before. I would assume that the OS does this intelligently so that when the IP address *does* suddenly appear at a later time, the application works seamlessly. That's something I will have to test. I might need to rethink my redundancy design with this new bit of knowledge. I have seen a number of incidents where pacemaker froze and I had no idea there was a problem until I did maintenance on the standby server (either rebooting it or stopping pacemaker) and the online host didn't notice it going down. Everything kept working, but the systems were in a state where no failover would have occurred in the event of a failure. I bet keepalived is a lot more stable than pacemaker. Thanks, Shawn
Re: Easy haproxy redundancy
On 8/27/2015 6:52 PM, Nathan Williams wrote: There's a sysctl for that, net.ipv4.ip_nonlocal_bind. Interesting. That's one I had never seen before. I would assume that the OS does this intelligently so that when the IP address *does* suddenly appear at a later time, the application works seamlessly. That's something I will have to test. I might need to rethink my redundancy design with this new bit of knowledge. I have seen a number of incidents where pacemaker froze and I had no idea there was a problem until I did maintenance on the standby server (either rebooting it or stopping pacemaker) and the online host didn't notice it going down. Everything kept working, but the systems were in a state where no failover would have occurred in the event of a failure. I bet keepalived is a lot more stable than pacemaker. Thanks, Shawn
Re: Easy haproxy redundancy
On Fri, 2015-08-28 at 01:25 +, Nathan Williams wrote: Yeah, keepalived handles the gratuitous arp on failover, it works nicely. I do miss the admin tools for pacemaker though. I'm AFK, but I'll write up a full explanation of our HA setup when I'm back at a PC. Cheers, Nathan Okay, here's the details on how we're doing this with keepalived. We have 2 OpenStack VMs with IPs on the internal network, a keepalived -managed VIP on the internal network that's added to each VMs allowed -address-pairs in neutron, and a floating IP from the external network mapped to the internal VIP (OpenStack floating IP is just a SNAT/DNAT). Depending on your environment, that's probably not super relevant, but it's essential to being able to have a public VIP under neutron, so I thought I'd mention it. We set the sysctl to enable binding to an address that we don't have. There's some other LB sysctl settings we set on the LB, but they're tunings, and not essential to the HA configuration. `sysctl net.ipv4.ip_nonlocal_bind=1` keepalived.conf[0]: keepalived manages the vip, runs scored health checks: the master has the highest score. keepalived also handles VIP migration and gratuitous arp to announce the change on failover. role-check.sh[1]: fail the master if it doesn't have the VIP. not strictly necessary, but we're paranoid. keepalive-notify.sh[2]: record history of state changes, last row used by role-check.sh to determine current state. It's been really stable over the last 8 months we've been running it; failover works really cleanly like you'd expect, there's been no unexplainable failovers we've run into so far, no failure to failover when it should. Without using LVS to do the actual load-balancing, there's no keepalived-associated tools I'm aware of to let you inspect the cluster state (as compared to pacemaker `crm_mon -Af`). It doesn't really matter with this simple cluster configuration, though; the master's the one with the VIP, so `ip addr show` tells you which one's the master, and the notify script-generated log file confirms it. You can manually force a failover by stopping the keepalived service on the master or adding an exit 1 to the top of the role-check.sh script (adjusting the scoring). Ditto for putting the standby into maintenance mode, you just ensure it can't end up with a higher score than the master. One thing to be aware of is that keepalived uses multicast by default, so you want to make sure every cluster uses a unique router-id, or your clusters might interfere with each other. Anyways, hope that helps! Feel free to ask if you have any add'l questions :) Regards, Nathan [0]: https://gist.github.com/nathwill/2463002f342cc75ae6b0 [1]: https://gist.github.com/nathwill/5475ff3b891c7f2b44b3 [2]: https://gist.github.com/nathwill/ac75957052bd75597780 On Thu, Aug 27, 2015, 6:11 PM Shawn Heisey hapr...@elyograg.org wrote: On 8/27/2015 6:52 PM, Nathan Williams wrote: There's a sysctl for that, net.ipv4.ip_nonlocal_bind. Interesting. That's one I had never seen before. I would assume that the OS does this intelligently so that when the IP address *does* suddenly appear at a later time, the application works seamlessly. That's something I will have to test. I might need to rethink my redundancy design with this new bit of knowledge. I have seen a number of incidents where pacemaker froze and I had no idea there was a problem until I did maintenance on the standby server (either rebooting it or stopping pacemaker) and the online host didn't notice it going down. Everything kept working, but the systems were in a state where no failover would have occurred in the event of a failure. I bet keepalived is a lot more stable than pacemaker. Thanks, Shawn
HAProxy - How to filter (all) Headers by Regex
Hello All, I was just wondering what is the best way if we want to filter all headers by certain regex to block invalid/malicious characters? I read on the documentation, CMIIW, but the example there only shown if we know the specific header name. Does anybody know how to filter all the http headers with specific regex, so we could discard all the traffic with the invalid headers and only forward the good one. Regards, Firman Gautama
perfect solutions
Remember! It won't sell if nobody knows you have it. You are receiving this email because we wish you to use our target email marketing service. We specialize in providing target email marketing services. We have worked on a number of projects and campaigns, all our packages are tailor made and designed according to your requirements. Increase your client base and market your product to millions or l et us bring the buying leads for you! Our goal is to increase your business sales 2-5 times than now. If you would require more information please send us an email and we would be glad to discuss the project requirements with you! Kind Regards Louis Contact: vivian...@sina.com Remember! It won't sell if nobody knows you have it.
Re: getting transparent proxy to work.
Hi Rich, That's why I wanted to fix your issue step by step. I didn't want to add too much complexity from first step. The question you're asking correpond to the last step. And as Igor mentionned, you should use keepalived to create a VIP which will be used as the default gateway by your web servers. You can simply use any of the VIP handling the web traffic. Baptiste On Thu, Aug 27, 2015 at 4:25 AM, Igor Cicimov ig...@encompasscorporation.com wrote: Obviously you need to have a separate VIP for the 10.10.130.30 and 10.10.130.31 and use that as a DGW on the backend servers. On Thu, Aug 27, 2015 at 9:24 AM, Rich Vigorito ri...@ocp.org wrote: In regards to setting up the default gateway on the webservers. im confused on how that would work with having a load balanced haproxy environment w/ keepalive. Attached is our diagram of haproxy/webserver architecture. When it says have the default gateway point back to haproyx, is it saying the VIP or the haproxy box ip? in the case default gateway being that of the vip how would that work because there are multiple VIP? in the the case of changing default gateway to haproxy box would would that work in a failover? I wouldnt assume that our setup is unique because im sure most people use haproxy for more than one website and most have haproxy load balanced w/ keepalive or pacemaker or something along those lines. Thanks in advance, --Rich -- *From:* Bryan Talbot bryan.tal...@ijji.com *Sent:* Thursday, August 20, 2015 4:27 PM *To:* Rich Vigorito *Cc:* Bryan Talbot; Baptiste; HAProxy *Subject:* Re: getting transparent proxy to work. On Thu, Aug 20, 2015 at 4:05 PM, Rich Vigorito ri...@ocp.org wrote: Reading this: http://blog.haproxy.com/2012/06/05/preserve-source-ip-address-despite-reverse-proxies/ about PROXY protocol, what needs to happen for PROXY protocol to be recognized by the web server? The webserver needs to support it. There is a (probably incomplete) list here: http://blog.haproxy.com/haproxy/proxy-protocol/ Im assuming the haproxy server already does? Yes, of course. -Bryan -- Igor Cicimov | DevOps p. +61 (0) 433 078 728 e. ig...@encompasscorporation.com http://encompasscorporation.com/ w*.* encompasscorporation.com a. Level 4, 65 York Street, Sydney 2000
Re: TCP_NODELAY in tcp mode
On Thu, 27 Aug 2015 20:34:35 +0300 Dmitry Sivachenko trtrmi...@gmail.com wrote: Hello, we have a client-server application which establish a long-living TCP connection and generates a lot of small request-response packets which need to be processed very fast. Setting TCP_NODELAY on sockets speed things up to about 3 times. Not I want to put a haproxy in the middle so it balances traffic between several servers. Something like defaults mode tcp frontend shard0-front bind *:9000 default_backend shard0-back backend shard0-back server srv1 srv1:3456 check server srv2 srv2:3456 check In such configuration application slows significantly. I suspect that setting frontend's and backend's sockets option TCP_NODELAY would help as it did without haproxy involved. Is there any parameter which allows me to set TCP_NODELAY option? Hello, The flag TCP_NODELAY is inconditionally set on each TCP (ipv4/ipv6) connections between haproxy and the serveur, and beetwen the client and haproxy. You can use strace for displying the system calls and ensure yourself that the TCP_NODELAY flags is set after each accept(), and after each connect(). Thierry
Re: Easy haproxy redundancy
There's a sysctl for that, net.ipv4.ip_nonlocal_bind. On Thu, Aug 27, 2015, 5:49 PM Shawn Heisey hapr...@elyograg.org wrote: On 8/24/2015 12:06 PM, Dennis Jacobfeuerborn wrote: There is no need to run a full Pacemaker stack. Just run HAProxy on both nodes and manage the virtual ips using keepalived. All of my bind statements are applied to specific ip addresses, not 0.0.0.0. If you try to start haproxy on a machine that is missing the address(es) that you are binding to (which describes the standby server in a redundant pair), it won't start. Public IP addresses redacted in the following partial log: root@lb4:~# service haproxy start ; service haproxy stop * Starting haproxy haproxy [ALERT] 238/183842 (32404) : Starting frontend fe-spark-80: cannot bind socket [RE.DAC.TED.78:80] [ALERT] 238/183842 (32404) : Starting frontend fe-spark-443: cannot bind socket [RE.DAC.TED.78:443] This is why I run redundant haproxy with a full pacemaker stack that starts haproxy and the gratuitous arps *after* the address resources have started. Thanks, Shawn
