Quick links Quick News Description Main features Supported Platforms Performance Reliability Security Download Documentation Live demo They use it! Commercial Support Add-on features Other Solutions Contacts External links Mailing list archives 10GbE load-balancing updated Contributions Coding style Known bugs visitors online Thanks for your support!

Ham Radio Software on Centos Linux

News February 28th, It fixes a few remaining bugs affecting 1. A few other minor issues were addressed. For the details, please check the announcement here.

Code and changelog are available here as usual. For more info, you can check the full 1. Code and changelogs are available here for 1. It fixes a few regressions introduced during 1. The most notable 1. There are a few other small things and doc fixes, for more info, it's recommended to read the announcement here.

It is considered by some of its contributors as the cleanest release ever produced. The development cycle for this version was focused on making it more reliable, more modular and more evolutive.

And it pays, because most of the recent new features did not require any core change, resulting in a more reliable core engine and less bugs expected over time.

There are too many improvements to list them here ; for a detailed description of the changes since 1. Consecutive to this update, the haproxy. Code and changelog are available here. A few issues were fixed. The first one is a final fix for the connection layer with the revert of the previous incorrect fix that went into 1.

Last, the systemd wrapper's signal delivery was fixed to ensure the signals are not lost and the wrapper always knows whether haproxy has finished starting or not. This ensures reload signals are not lost while the config is being parsed. The complete announcement is available here. It completes a 13 months development cycle with some nice features that have been awaited for a long time, and managed to fix all the remaining bugs that were reported after the 1.

The main last features are the support for starting the process with a configuration containing servers which do not resolve and to let them resolve later, the ability for the DNS resolver to finally mark a server as temporarily down on resolution failure and obviously up again on successinitial support for OpenSSL 1. We also merged a third device detection engine, WURFL developed by Scientiamobile.

It's a bit late in the development cycle for such stuff but the code is very well isolated and very clean so there's no reason not to take it. It is supposed to be the last version before the final release. Code cleanups are more than welcome and needed in some areas. A few of them area already ongoing.

It added 19 new commits after version 1. So this is the first 1. One change that may affect some users is that we removed the magic consisting in assigning a server's check port to the same port as the first port of the first "bind" directive in the listener if any. It doesn't make sense at all, is not documented, doesn't work in many situations eg: Normally nobody uses this anymore since 1.

Developers may notice that now everything is rebuilt when they modify a ". Non-developer users are protected against easy mistakes and we are not bothered by a dependency hell. A number of build fixes for OpenBSD were merged. In fact it would not build anymore since 1.

I'm surprized that we didn't receive any complaint in one year, in the past people would report OpenBSD breakage. Maybe these users are now on FreeBSD which seems to work very well. Another new action is the "track-sc" for http-response. This is nice to for counting certain response events.

Abkürzungen - Info

The "show tls-keys" CLI command can now display the current secrets. There were some filter changes. We can also decode the Netscaler's CIP protocol which is an alternative to haproxy's PROXY protocol.

We now have a few new sample fetch functions reporting various TCP-level information on Linux, FreeBSD and NetBSD such as RTT, number of retransmits, etc. It can make logs more usable during troubleshooting. And finally the command-line "-f" argument now supports directories in addition to file names.

Files are loaded in alphabetical order. It is convenient for certain users, but beware of the orderning, use at your own risk! The remaining patches are minor bugs and documentation. All users of 1. This also marks the last 1. A number of important bugs were fixed since last releases. Some of them impact 1. A few Lua bugs were fixed as well, one of them causing a segfault and another one dead connections. Sample fetch functions were protected against misuse of layer 7 in tcp connection rules causing a segfault.

And session variables could also be improperly used in connection rules with the same effect. For the less important fixes, some race conditions were addressed in the systemd wrapper possibly causing the orphaned processes some people were experiencing.

The compression code was already adapted to use them. More to come later, possibly traffic shaping. The stats have been improved: It is now possible to manipulate environment variables from within the config files, this will solve the problem people are facing when migrating to systemd since it doesn't allow reloaded processes to see changes in environment variables. As it's been a long time for all versions, users are encouraged to upgrade. Code and changelogs are available here as usual. For the last 4 months, a few fixes have accumulated there, including the annoying one striking again on http-send-name-header.

Another one may cause the old process to die during a soft reload when a proxy references a disabled peers section. The next annoying one affects those who set memory limits to their processes, as the memory size computation was accidently performed on bits which is limited by todays standards 4GB max so a typical 5 GB allocation would result in 1 GB only due to integer overflow.

The remaining patches are for minor bugs, cleanups and doc updates. For the vast majority of users there's no emergency to update. However if you're deploying now, please consider using this version in order to avoid these bugs later.

The small number of bugs 3 in one week is much smaller than what we had in 1. As usual, code and changelog are available here. It includes a lot of new features gathered from many contributors during 16 months of development and stabilization. There are too many features to list here. Among the most user-visible changes, we can cite the simpler handling of multiple configuration files, the support for quotes and environment variables in the configuration, a significant reduction of the memory usage thanks to a new dynamic buffer allocator, notifications over e-mail, server state keeping across reloads, dynamic DNS-based server address resolution, new scripting capabilities thanks to the embedded Lua interpreter, use of variables in the configuration to manipulate samples, request body buffering and analysis, support for two third-party device identification products DeviceAtlas and 51Degreesa lot of new sample converters including arithmetic operators and table lookups, TLS ticket secret sharing between nodes, TLS SNI to the server, full tables replication between peers, ability to instruct the kernel to quickly kill dead connections, support for Linux namespaces, and a number of other less visible goodies.

The performance has also been improved a lot with support for server connection multiplexing, much faster and cheaper HTTP compression via libslz, and the addition of a pattern cache to speed up certain expensive ACLs. The great flexibility offered by this version will allow many users to significantly simplify their configurations. Some users will notice a huge performance boost after they enable the features designed for them.

This release also marks the opening of the 1. The next release date for 1. This time, in order to satisfy more contributors, we'll have a 3-phase development cycle. The first phase ending in March will merge the most sensitive changes, possibly causing a lot of breakage. It is only for developers. A second phase, ending in June, will be dedicated to fixing the breakage and will still allow small improvements to be made as long as they are not expected to cause regressions.

It is possibly where we will decide to revert some of the early breakage if some features are too broken. Enthousiasts may start to test during this phase and report issues. The last phase ending in September will be dedicated to the final polishing, portability issues and doc updates, and should be acceptable for most early adopters. So let's get back to the whiteboards now.

A few extra features were merged, among which server state conservation across reload, Lua applet registration, RFCcompliant log header and structured data extension, cpu-map support on FreeBSD, TCP silent-drop action, and support for any address family in Lua co-socket. Please check for the details in the mailing list's announce.

Please test it this week so that we can group last fixes and doc updates next week for a release in less than 2 weeks. Still some work to be done before final 1. Please test it if you haven't yet tested 1. In some cases, a client might be able to cause a buffer alignment issue and retrieve uninitialized memory contents that exhibit data from a past request or session.

I want to address sincere congratulations to Charlie Smurthwaite of aTech Media for the really detailed traces he provided which made it possible to find the cause of this bug. Every user of 1. CVE was assigned to this bug. The most important part is the replacement of the dh-param groups provided by default in order to avoid the issues brought with logjam. Some bugs were found in the tcp-checks rules processing and were fixed. If you use tcp-checks, you'd be safe with this update.

Another one is an issue that was reported in 1. Now we apply NOLINGER to avoid this. The number of changes is as huge as for dev1, in part due to many last-minute features being rushed into it. The more detailed changelog can be read here in the announce. Server state conservation across reloads is still being scottrade options expiration and make money using craigslist hopefully be merged before dev3.

The first one describes the protocol itself while the second one is specific to the header compression mechanism called Bollinger bands s&p 500. HAProxy has experienced a major internal architecture redesign during the 1.

We expect to market rate of return on stock calculator it by the end of the year, during the 1. Two of them may result in a crash with very specific configurations. A number of fixes to comply with RFC were made. Till now we used to comply with but it was not strict enough and could cause interoperability issues in some corner cases. A new feature was backported: Another improvement consists in a relax of the restriction between peers and nbproc.

Now it is possible to use peers provided that the whole section is only used by tables belonging to the same process.

This makes it easier to run SSL offloading in multiple processes now. Complete rewrite of HAProxy in Lua As some might have noticed, HAProxy development is progressively slowing down over time. I have analyzed the situation and came option strategies with vix and vstoxx futures the following conclusions: Ten years ago, version 1.

Today, mainline is lines, or 16 times larger. I'm currently on 4. Multiply this by about builds a day and you see that half an hour is wasted every single day dedicated to development. In fact, most of those who are proficient in C already have a job and little spare time to dedicate to an opensource project. In parallel, I'm seeing I'm getting old, I turned 40 last year and it's obvious that I'm not as much capable of optimizing code as I used to be.

I'm of the old school, still counting the CPU cycles it takes a function to execute, the nanoseconds required to append an X-Forwarded-For header or to parse a cookie. And all of this is totally wasted when people run the software in virtual machines which only allocate portions of CPUs ie they switch between multiple VMs forex solutions india high rateor install it in front of applications which saturate at requests a second.

Recently with the Lua addition, we found it to be quite fast. Maybe not as fast as Currency rates saudi arabia pakistan, but Lua is improving and C skills are diminishing, so I guess that in a few years the code written in Lua will be much faster than the code we'll be able to write in C.

Thus I found it wise to declare a complete rewrite of HAProxy in Lua. It comes with many benefits. First, Lua is easy to learn, we'll get many more developers and contributors. One of the reason is that you don't need to care about resource allocation anymore.

Machines are huge nowadays, much larger than the old Athlon XP I was using 10 years ago.

Second, Lua doesn't require a compiler, so we'll save 30 sqlinternalconnectiontds validateconnectionforexecute a day per builds, this will definitely speed up development for each developer.

And we won't depend on a given C compiler, won't be subject to its bugs, and more importantly we'll be able to get rid of the few lines of assembly that we currently have in some performance-critical parts. Third, last version of HAProxy saw a lot of new sample fetch functions and converters. This will not be needed anymore, because the code and the configuration will be mixed together, just as everyone does with Shell scripts.

Example: Sampling Configuration - Technical Documentation - Support - Juniper Networks

This means that any config will just look like an include directive for the haproxy code, followed by some code to declare the configuration. It will then be possible to create infinite combinations of new functions, and the configuration will have access to anything internal to HAProxy.

In the end, of the current HAProxy will only remain the Lua engine, and probably by then we'll find even better ones so that haproxy will be distributed as a Lua library to use anywhere, maybe even on IoT devices if that makes sense anyone ever dreamed simple stock how much do stockbrokers make on wall street having haproxy in their watches?

This step forward will save us from having to continue to do any code versionning, because everyone will have his own fork and the code will grow much faster this way.

That also means that Git will become useless for us. In terms of security, it will be much better as it will not be possible to exploit a vulnerability common to all versions anymore since each version will be different.

HAProxy Technologies is going to accurate binary options system magnet a lot of resources to this task. Obviously all the development team will work on this full time, but we also realize that since customers will not be interested in the C version anymore after this public announce, we'll train the sales people to write Lua as well in amazon stock market ticker symbols to speed up development.

We'll continue to provide an enterprise version forked from HAPEE that we'll rename "Luapee". It will still provide all the extras that make it a professional solution such as VRRP, SNMP etc and over the long term we expect to rewrite all of these components in Lua as well. The ALOHA appliances will change a little bit, they'll mostly be a Lua engine to run all that code, so we'll probably rename them HALUA.

And given that the appliance's goal has always been to take profit of the hardware and kernel to set forwarding options sampling family inet output interface improve the capabilities, we'll have free hands to port other performance-critical parts in Lua, including maybe the currently aging Linux kernel which also happens to be written in C. Once everything is ported, I intend to use my old skills in the domain of microarchitecture to design a native Lua processor that will run in our appliances so that all the code runs in silicon and ends up being much faster than what we currently have in C.

I'm quite aware that some parts will be tedious. Rewriting OpenSSL in Lua will neither be easy nor fun. But it's the price to pay to get fast and affordable security. Due to the huge amount of work, we'll postpone the 1.

I hope everyone understands that we have no other choice. One of them was not exactly a bug since it used to work as documented, but as it was documented to work in a stupid and useless way I decided to backport it anyway.

It's the "http-request set-header" action which used to remove the target header prior to computing the format string, making it impossible to append a value to an existing header, or to have to pass via a dummy header, adding to the complexity. Now the string is computed before removing the header so that there's no more insane tricks to go through.

One important fix targets users running on 1. No less than 3 bugs in direct relation with this feature were fixed, two of them capable of crashing the process under certain conditions. Another important bug in 1. Other fixes are not really important and were accumulated over 10 months. Considering that the last 1. Sorry for the inconvenience. At the time of writing, the draft is in the "Last Call" state which basically means that unless something critical is discovered, it will soon be adopted in its current form.

Here "soon" means "around a few weeks". What will this change? Probably not much at the beginning, but a lot soon.

A number of sites already support Set forwarding options sampling family inet output interface for the same reasons right now but SPDY is constantly evolving and requires more attention from users who have to update often. But this will cause a new issue: This will immediately have two impacts: Alarmists used to say that the 40 Tbps trans-atlantic total capacity is almost saturated and hard to upgrade, we'll see if that's true.

The second effect is that origin servers will get a significant traffic increase, which is good for ADC vendors as well as for CDNs which will get many new customers and increase their revenue. Sadly, in a number of poorly connected countries where client-side caches are critical to the survival of the Internet, CDNs will not be able to help and the situation will get even worse.

That's also the case for a number of mobile phone operators who can observe high cache hit ratios today. What will very likely happen to address these situations is that ISPs and mobile phone operators will start to propose a faster Internet access to their customers in exchange for a root cert how did albert talton make counterfeit money they can happily install in their browser so that the operator can decipher SSL traffic on the fly and cache again.

End users are already prepared to accept this because they don't care at all about their privacy when it comes to whatever they do with their smartphone, otherwise they would always close their apps and type a password to access their emails.

And the next logical step is that mobile phones sold by these operators will already have the root cert pre-installed in order to save a complex operation from the end user. And that will lead to an interesting situation.

First, SSL offloading solution vendors will happily see their sales increase. This chain is extremely fragile already and is regularly being abusedbut now it could become the norm not to trust SSL anymore when rogue CAs becomes mandatory to access the net. Fortunately, a few solutions are being worked on. On the HTTP working group they're called "Trusted Proxies" or "GET https: They consist in letting the end user choose what can be deciphered and what cannot.

That's how we could get a better Internet for everyone, with better caching and better privacy at the same time. Not sure it will happen by though, but we should do whatever we can for this to happen! Last release of the year! Most of the fixes in this version are related to how we deal with out-of-memory situations.

This normally interests nobody except those who run many instances on memory-bound servers. There was a very unlikely but possible case of crash when it was not possible to allocate a small chunk of memory I managed to reproduce it after a long time during extremely aggressive tests. There are a few fixes on tcp-checks, one for a bug causing some random contents to be analysed, another one where quick acks were disabled when there was no data to send, causing ms delays when "option tcp-check" was specified alone.

Zenon Chaczko | University of Technology Sydney

Another bug concerned proxies disabled in the configuration which could under some circumstances cause a segfault upon startup during the process mask propagation between frontends and backends. The rest is mostly harmless, so keep cool, no rush if you're already running 1. In short, some issues with out-of-memory conditions were fixed both in the SSL part and in the session management.

Now it should not be possible to crash haproxy even when running with artificially low memory limitations. Cyril fixed a problem with the agent check accidently inheriting the SSL mode of regular checks.

Denys Fedoryshchenko found that TCP captures could cause random crashes when not using HTTP mode due to the capture pointers not yet being initialized. Krisztian Kovacs fixed a Proxy Protocol parsing bug. Thierry Fournier fixed a bug that appears when loading many time the same ACL from a file, causing it to grow and slow down for some linear matches eg: A few minor fetches were backported as they make it easier to take action based on the process ID or the stopping status.

The rest are minor bug fixes and improvements. Users must definitely upgrade, especially if using TCP captures or running under constrained memory conditions. Godbach fixed a bug which appears only when users force tune. There's no security impact here given that such configurations cannot be used in production. I preferred to issue a new version so that everyone can upgrade without trouble. If you already run with 1. The probability to hit it is so low that it has existed since v1. A bug where the PROXY protocol is used with a banner protocol causes an extra ms delay for the request to leave, slowing down connection establishment to SMTP or FTP servers.

The way original connection addresses are detected on a system where connections are NAT'd by Netfilter was fixed so that we wouldn't report IPv4 destination addresses for v6-mapped v4 addresses.

This used to cause the PROXY protocol to emit "UNKNOWN" as the address families differred for the source and destination! John Leach reported an interesting bug in the way SSL certificates were loaded: That's all for this version. Nothing critical again, but we're just trying to keep a fast pace to eliminate each and every bug.

Since there was no rush here, it can be the good timing to upgrade to a reasonably stable version after testing it calmly: This bug was introduced in 1.

This bug can cause haproxy to crash if a number of conditions are met together. Basically, we need a client which can upload multiples of 2GB of POST data much faster than the server can read, and the server must accept all these data slowly enough. If all of this happens, it is possible during the roll-over at every 2GB that the chunk parser tries to parse a chunk length out of the input buffer, causing haproxy to crash.

In practice, it can essentially be exploited when the attacker controls both the client, the server, and the timing. This cannot be used to modify data nor execute code though, it's only a denial of service. Another bug was a possible busy loop in tcp-request content track-sc rules. Other bugs are less important and can be found in the changelog available with the code here. Essentialy, a possible memory leak un SSL DHE exchanges, and a possible memory corruption when building the proxy protocol v2 header.

For sure few people will feel impacted, but better release a new version while everything else is calm. The source code and changelog are available here. The first one can cause some sample fetch combinations to fail together in a same expression, and one artificial case but totally useless may even crash the process.

The second one is an incomplete fix in 1. Hash-based balancing algorithms and http-send-name-header may fail if a request contains a body which starts to be forwarded before the contents are used.

A few other bugs were fixed, and the max syslog line length is now configurable per logger. As usual, the source code and changelog are available here. For more information, please consult the source code and changelog here. Also today I was pleased to receive a bottle of Champagne sent by our friends at Loadbalancer. In fact, there appears to be a default limit of requests per second when "--rate" is not specified. I set it to 1 million and ran the test again.

Since my machine is a Core2 Quad at 3 GHz, I fired 3 httperf against one haproxy process. I finally assembled my new machines and installed the donated Gig Myricom NICs. I ran a few benchmarks. It's possibly the highest bitrate achieved to date with an opensource load-balancer! BTW, even most commercial ones are commonly limited to 4 Gbps by hardware design. What's a bit frustrating for a precision-tweaker like me is that those NICs work out-of-the box on dirt cheap hardware, there's almost no joy passing beyond the first 4 Gbps: Some of you might have already got their hands on this.

For those who don't know yet, this beautiful piece of art is a 10 Gbps Ethernet NIC from Myricom. For a long time, I had been tempted by their legendary high performance network cards, which were said everywhere to be able to saturate a 10 Gig wire under Linux without putting too much stress on the CPU, using a mainstream opensource driver, and without resorting to dirty tricks such as TOE.

What would a performance addict like me need more? I finally decided to mail these guys and described how I'm currently used to benchmark HAproxy with aggregated Gigabit NICs, with a minimum of 4 NICs in a setup 1 for the client, 2 for the proxy, 1 for the server.

He explained to me that he was pleased to offer me 4 NICs with cables, plus one spare of each just in case, as their contribution to the project And if it would not be enough for some of you to find them really cool, he also provided me with french-speaking contacts, free access to their support and important advices for the choice of motherboards to get the best out of those wonderful NICs!

I don't even know the polite words to say in such circumstances: This evening, I noticed that they arrived at EXOSEC. After leaving the customer's, I went back there to find this big parcel on my desk, with its contents very carefully packed. I must say that I was both very excited and extremely careful while opening the packaging. The first thing I noticed after extracting the first NIC from its packaging was that it had a very clean design, as can be seen on this photo.

They are also very thin as shown on the picture on the rightso there will be no problem putting two of them side-by-side in the proxy. The CX4 connector looks a bit fragile, but careful manipulation is the minimal requirement to use the highest speed standard Ethernet. From what I understood, this is the same connector as used on Infiniband, except that 10GE has terminators on the board.

Well, obviously, there are very nice companies out there who deserve to be talked about! Their very generous support to open source projects leaves many others far behind. People say that Santa Claus lives in the North Pole, but now I know he lives in Arcadia in California: Be sure to read about my first test results here.