Re: UP 2/3 status
Hi Robin, Op 28 sep. 2013, om 05:54 heeft Robin Lee Powell rlpow...@cytobank.org het volgende geschreven: How many server elements does the backend have? That sounds like 2 out of 3 of my servers are up to me. Hm, perhaps. I do have 2 backends, so that makes 3 if you add the frontend and count proxies: frontend fe bindx.x.x.x:80 acl url-testurl_beg /test use_backend backup if url-test default_backend ha backend test server app11 10.0.0.71:80 backend ha balance roundrobin server app11 10.0.0.71:80 check backup server app12 10.0.0.72:80 check But if either proxy would be down (when I get a UP 2/3), I would hardly consider that as an up-state. More like DOWN 1/3. Also, the HAProxy server logs don't show any abnormal behavior when I got the UP 2/3 state (active was yes). So should I be bothered with UP 2/3 or is it save just to ignore it. Mark -Robin On Sat, Sep 28, 2013 at 03:37:43AM +0200, Mark Ruys wrote: Hi, I'm using a Nagios plugin to monitor the HAProxy status. Now and then, HAProxy reports UP 2/3 as a backend status in the statistics. I wonder, what does 2/3 mean? Mark Ruys --- dr M.P.J. Ruys (PhD) ::Peercode Oudenhof 4c, 4191NW Geldermalsen, The Netherlands Web site and travel directions: www.peercode.nl Phone +31.88.0084124 :: Mobile +31.6.51298623 --- dr M.P.J. Ruys (PhD) ::Peercode Oudenhof 4c, 4191NW Geldermalsen, The Netherlands Web site and travel directions: www.peercode.nl Phone +31.88.0084124 :: Mobile +31.6.51298623
RE: Static haproxy/openssl build error
On 2013-09-27 21:17, Lukas Tribus wrote: Hi Julien, I'm attempting to build HEAD with a statically compiled openssl, and get the following error: [...] $ /tmp/staticlibssl/bin/openssl version OpenSSL 1.1.0-dev xx XXX Any idea what could be missing here? Try stable OpenSSL 1.0.1e, that should work. I did, and I get the exact same error. The problem happens on Debian Squeeze. My laptop on Fedora 19 doesn't have the issue. - Julien
Re: Ratelimiting issue
You could've used haproxy-ss-LATEST or haproxy-ss-20130924 to avoid the manual patching. Oh, okay. I am guessing, this was some bug which existed on 1.5-dev18, which got fixed on the later versions. Let me know. That seems likely. Maybe related to the fixes around commit 563eef4e30 (MEDIUM: counters: factor out smp_fetch_sc*_trackers): http://haproxy.1wt.eu/git?p=haproxy.git;a=commit;h=563eef4e30 Ah, ok. Thanks a lot, for the help. - Karthik Iyer
Re: UP 2/3 status
28/09/2013 03:37, Mark Ruys wrote: I'm using a Nagios plugin to monitor the HAProxy status. Now and then, HAProxy reports UP 2/3 as a backend status in the statistics. I wonder, what does 2/3 mean? Foreword: I have never used Nagios. You wrote backed status, but... could it be server status? In this case UP 2/3 could mean the server is up, 2 checks out of 3 were successful, i.e. one check failed. Cheers .marcoc
Re: AW: GA Release of 1.5
Hi guys, On Tue, Sep 24, 2013 at 09:07:23PM +0200, Lukas Tribus wrote: Hi everyone, An important reason to release the SSL feature set as is could be for the potential to release timely security fixes when vulnerabilities or exploits are discovered. Security problems are fixed in both 1.5 and 1.4 branches at the same time with new releases, see 1.4.24/1.5-dev19 and 1.4.23/1.5-dev18. Willy is very well aware that 1.5 is widely used in production. Yes, clearly. we're using it in the ALOHA and at a number of customers under specific support. In practice, it happens that 1.5 is in prod at larger sites than 1.4, not because it's faster, but because it provides the track counters that larger sites need to counter abuses and DoS attacks. Unfortunately we don't have the resources to maintain a branch to which we could backport relevant fixes, not to mention the overhead of managing any security related fixes. Willy is very transparent with security issues and its fixes are usually just a small patches, so the backport is really only a question of downloading a single patch and applying it. Well, I'd say that there are two ways to deal with backports : - use 1.4 with some feature backports (eg: proxy protocol maintained by Cyril) - use 1.5 with backport for bug fixes (including security fixes). The first solution probably is the easiest one if no 1.5-specific features are needed. Simply apply a few patches on top of the latest 1.4 snapshot and/or release and that's all. The second one needs to invest time. There's no alternative. We do this for our ALOHA product and when we have to fix some issues, we only backport fixes to the version we have chosen as a base for the product branch. And I guess that our colleagues at Loadbalancer.org do the same, simply because it is the only way to use a rolling version and provide responsible updates at the same time to end users. Also, in contrast to other projects, Willy and the mailing list do provide full support for 1.5 and appreciate bug reports for it. So if you have troubles backporting a security relevant fix, I think the mailing list will help without hesitation. Yes, for sure! I do completely understand your worries about using a development version in production. Like I said, if this is a showstopper for deploying HAproxy, then you need commercial support: With no doubt. Tu put it clear, when it's *your* business, you probably want to save a few k$ and do the job yourself. But when you have a boss with a budget or simply customers paying for the service, you'll probably prefer to pay some company to save your ass. That's why we're not afraid of working on opensource and selling integrated products at the same time, there's place for everything and there's demand for everything. If you don't have the time and need those bleeding edge features today, then you should probably stick to a commercial solution, like those from exceliance.fr or loadbalancer.org. I'm not sure if either of these offer websocket+SSL support, but certainly worth investigating. I should've made it clear: Exceliance products are based on HAProxy *1.5-dev* and Willy is actually an employee (or even a founder). So if your configuration does work with haproxy 1.5, Exceliance will get the job done (and the fees will probably fund further development of HAProxy in one way or another). Confirmed :-) Given the code contributions of loadbalancer.org I highly suspect they have some HAproxy based products as well. Yes, and the best is that we almost never compete and even work together from time to time in the back yard to get some bugs fixed ! With the knowledge that server-side keep-alives aren't currently supported together with SSL we could plan our production deployment to take this into account until a future release does support the combination. Documentation could very well reflect these limitations and serve to manage users expectations. A single OSS product will never cover all the aspects and requirements all the different users have, but it doesn't need to, imho. BTW, the lack of server-side keep-alive is clearly documented in the configuration manual. Thats why we (in the IT industry) have commercial products, paid 24/7 support, SLAs and features requests with business cases behind it, even if the actual source code is open. Have CentOs, but want to sleep better? Get RHEL with commercial support. That's exactly the same. Now let me give some more info about server-side keep-alive. There are two reasons why I want this to be complete before releasing 1.5. Usually, keep-alive to application servers is useless or even counter-productive if connections cannot be multiplexed (which is the default case when you don't have the *guarantee* that the application supports this). However, there is a situation where you need server-side keep-alive : NTLM authentication. NTLM is broken in that it
Namjob -Namibia's Job portal
Hi, Namjob.com is Namibia's online job portal where Companies can post Job / Vacancies to reach out CVs registered with us. namjob.com is a community Project, which provides a common platform for companies, headhunters and job seekers to liaise quickly and effectively. We are giving FREE Job posting for companies in Namjob.com. Register as Employer / Recruitment Agent to post your jobs - http://www.namjob.com/wp-login.php?action=registerusertype=employer Job Seekers http://www.namjob.com/wp-login.php?action=register to reachout Employers and apply for job. Like https://www.facebook.com/namibiajobportal for Interview and Management Tips and some Work jokes. Regards Customer care Team Namibia's No 1 Job Portal www.namjob.com http://www.namjob.com/?usertype=employer@ www.namjob.com NB:This is an announcement and a promotional mail. If you find this mail unsolicited, please reply with Remove in the subject line and we will not send any further mail.
Re: Static haproxy/openssl build error
Hi Julien, On 10:35 Sat 28 Sep , Julien Vehent wrote: On 2013-09-27 21:17, Lukas Tribus wrote: Try stable OpenSSL 1.0.1e, that should work. I did, and I get the exact same error. The problem happens on Debian Squeeze. My laptop on Fedora 19 doesn't have the issue. HAProxy's build system does not currently support static linking against openssl. The reason it works on Fedora 19, is probably because the system already ships OpenSSL 1.0.1 in the system library path; I bet if you do an ldd against the generated haproxy binary it will be dynamically linked against the system's OpenSSL, not statically against your own version. The only way to statically link against OpenSSL would be to patch HAProxy's Makefile to do more or less what is done with static PCRE: pass -Wl,-Bstatic before -lssl and -Wl,-Bdynamic afterwards. The following patch should do it (although it should really introduce a new flag): diff --git a/Makefile b/Makefile index 5e12af8..fc4d1bc 100644 --- a/Makefile +++ b/Makefile @@ -521,7 +521,7 @@ ifneq ($(USE_OPENSSL),) # to specify -I and -L if your OpenSSL library is not in the standard path. BUILD_OPTIONS += $(call ignore_implicit,USE_OPENSSL) OPTIONS_CFLAGS += -DUSE_OPENSSL -OPTIONS_LDFLAGS += -lssl -lcrypto +OPTIONS_LDFLAGS += -Wl,-Bstatic -lssl -lcrypto -Wl,-Bdynamic OPTIONS_OBJS += src/ssl_sock.o src/shctx.o ifneq ($(USE_PRIVATE_CACHE),) OPTIONS_CFLAGS += -DUSE_PRIVATE_CACHE -- Regards, Apollon PS: personally I wouldn't link statically against OpenSSL. I'd just co-install libssl1.0.0 along with the system's libssl0.9.8.
