Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

2015-12-14 Thread Willy Tarreau
Hi Lukas,

On Tue, Dec 15, 2015 at 01:44:18AM +0100, Lukas Tribus wrote:
> Hey guys,
> 
> thanks everyone involved in this contribution!
> 
> Been meaning to give the patch-set a run last week, but things
> came up last minute (as they always do). I hope I can spend
> some time with it shortly.

Cool!

> > On which branches was this merged ? 1.5, 1.6 or both?
> 
> Its a new feature, its in the development branch 1.7-dev only.
> 
> Perhaps we can tag a new 1.7-dev1 to encourage testing.
> 
> In every case, it will be in tomorrows 1.7-dev0-201512116 snapshot [1],
> for everyone preferring tarballs over git.

That's a good idea, but before this I really want to fix the Lua crash
that was reported. We've worked on it with Thierry and it's all but
simple, so I'm interested in getting feedback once we can propose
something.

Regards,
Willy




Re: LUA - File not found

2015-12-14 Thread Hugues Alary
Someone answered me in a private message and pointed out I must be running
in a chroot.

This is indeed the issue. Removing the chroot global option fixes this.
I'll see if I can find a way to keep running haproxy all the while running
in a chroot.

-Hugues

On Mon, Dec 14, 2015 at 6:13 PM, Hugues Alary  wrote:

> Hey there,
>
> I've been playing with haproxy 1.6.2 and the LUA feature and I'm running
> into the following issue:
>
> I wrote a LUA script that loads an external library called "lua-requests".
>
> I installed luarocks, then installed lua-requests via luarocks.
>
> Now, my LUA scripts contains the following line:
>
> local requests = require("requests")
>
> But when I run HAProxy, I get the following error:
>
> [ALERT] 347/175818 (4914) : Lua function 'send_varnish_ban': runtime
> error: /etc/haproxy/send_varnish_ban.lua:2: module 'requests' not found:
> no field package.preload['requests']
> no file '/usr/local/share/lua/5.3/requests.lua'
> no file '/usr/local/share/lua/5.3/requests/init.lua'
> no file '/usr/local/lib/lua/5.3/requests.lua'
> no file '/usr/local/lib/lua/5.3/requests/init.lua'
> no file '/usr/share/lua/5.3/requests.lua'
> no file '/usr/share/lua/5.3/requests/init.lua'
> no file './requests.lua'
> no file './requests/init.lua'
> no file '/usr/local/lib/lua/5.3/requests.so'
> no file '/usr/lib/x86_64-linux-gnu/lua/5.3/requests.so'
> no file '/usr/lib/lua/5.3/requests.so'
> no file '/usr/local/lib/lua/5.3/loadall.so'
> no file './requests.so'.
>
> But, the file /usr/local/share/lua/5.3/requests.lua does exist (ls does
> show me the file). I even copied/pasted it into my /etc/haproxy/ folder,
> and HAProxy still can't find it.
>
> I tried changing the permissions of the file to 777 just to make sure this
> wasn't the problem, still no luck.
>
> Typing require("requests.lua") in the LUA interactive interpreter works
> perfectly.
>
> I added a print(package.path) in my HAProxy LUA script, and the value
> seems correct: "
> /usr/local/share/lua/5.3/?.lua;/usr/local/share/lua/5.3/?/init.lua;/usr/local/lib/lua/5.3/?.lua;/usr/local/lib/lua/5.3/?/init.lua;/usr/share/lua/5.3/?.lua;/usr/share/lua/5.3/?/init.lua;./?.lua;./?/init.lua
> "
>
> I've been fiddling for the past few hours with no luck.
>
> Any idea why HAProxy can't seem to find a file that clearly exists?
>
> Thanks!
> -Hugues
>


LUA - File not found

2015-12-14 Thread Hugues Alary
Hey there,

I've been playing with haproxy 1.6.2 and the LUA feature and I'm running
into the following issue:

I wrote a LUA script that loads an external library called "lua-requests".

I installed luarocks, then installed lua-requests via luarocks.

Now, my LUA scripts contains the following line:

local requests = require("requests")

But when I run HAProxy, I get the following error:

[ALERT] 347/175818 (4914) : Lua function 'send_varnish_ban': runtime error:
/etc/haproxy/send_varnish_ban.lua:2: module 'requests' not found:
no field package.preload['requests']
no file '/usr/local/share/lua/5.3/requests.lua'
no file '/usr/local/share/lua/5.3/requests/init.lua'
no file '/usr/local/lib/lua/5.3/requests.lua'
no file '/usr/local/lib/lua/5.3/requests/init.lua'
no file '/usr/share/lua/5.3/requests.lua'
no file '/usr/share/lua/5.3/requests/init.lua'
no file './requests.lua'
no file './requests/init.lua'
no file '/usr/local/lib/lua/5.3/requests.so'
no file '/usr/lib/x86_64-linux-gnu/lua/5.3/requests.so'
no file '/usr/lib/lua/5.3/requests.so'
no file '/usr/local/lib/lua/5.3/loadall.so'
no file './requests.so'.

But, the file /usr/local/share/lua/5.3/requests.lua does exist (ls does
show me the file). I even copied/pasted it into my /etc/haproxy/ folder,
and HAProxy still can't find it.

I tried changing the permissions of the file to 777 just to make sure this
wasn't the problem, still no luck.

Typing require("requests.lua") in the LUA interactive interpreter works
perfectly.

I added a print(package.path) in my HAProxy LUA script, and the value seems
correct: "
/usr/local/share/lua/5.3/?.lua;/usr/local/share/lua/5.3/?/init.lua;/usr/local/lib/lua/5.3/?.lua;/usr/local/lib/lua/5.3/?/init.lua;/usr/share/lua/5.3/?.lua;/usr/share/lua/5.3/?/init.lua;./?.lua;./?/init.lua
"

I've been fiddling for the past few hours with no luck.

Any idea why HAProxy can't seem to find a file that clearly exists?

Thanks!
-Hugues


high end places'best choice-led mini recessed spotlight kits

2015-12-14 Thread june
DearPurchasemanager,=   =;  
2016upgradedledminirecesseddownlightreleased.with=thefollowingfeatures: 
 =; 1)220lm*6pcs  =; 2)2700-5000Koption  =;  
3)outputvoltage:12VDC-24VDC  =; 4)weatherproofgrade:IP64  =; 
5)CRI>80   bestwishesJunewww.sunriseleds.com

RE: Contribution for HAProxy: Peer Cipher based SSL CTX switching

2015-12-14 Thread Lukas Tribus
Hey guys,

thanks everyone involved in this contribution!

Been meaning to give the patch-set a run last week, but things
came up last minute (as they always do). I hope I can spend
some time with it shortly.



> On which branches was this merged ? 1.5, 1.6 or both?

Its a new feature, its in the development branch 1.7-dev only.

Perhaps we can tag a new 1.7-dev1 to encourage testing.

In every case, it will be in tomorrows 1.7-dev0-201512116 snapshot [1],
for everyone preferring tarballs over git.



Regards,

Lukas


[1] http://www.haproxy.org/download/1.7/src/snapshot/   
  


Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

2015-12-14 Thread Olivier Doucet
Hello,


2015-12-14 23:31 GMT+01:00 Willy Tarreau :

> On Mon, Dec 14, 2015 at 08:16:33PM +, Dave Zhu (yanbzhu) wrote:
> > Thank you Willy and Emeric for their efforts in the design, and thanks to
> > everyone else for all your support and help in testing/debugging this
> > feature!
> >
> > I靶e attached the DOC patch to this message. Please take a look and let me
> > know if you see any errors in formatting that needs fixed.
>

There is only a missing word on the first sentence if I'm correct :
"There are cases where it is desirable _to_ support multiple key types"

On which branches was this merged ? 1.5, 1.6 or both ?
I'm eager to test it.

Olivier


Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

2015-12-14 Thread Willy Tarreau
On Mon, Dec 14, 2015 at 08:16:33PM +, Dave Zhu (yanbzhu) wrote:
> Thank you Willy and Emeric for their efforts in the design, and thanks to
> everyone else for all your support and help in testing/debugging this
> feature!
> 
> I¹ve attached the DOC patch to this message. Please take a look and let me
> know if you see any errors in formatting that needs fixed.

I've just removed the extra spaces at the end of lines while merging it
but that was all, everything looked good. You can check tomorrow morning
on the HTML doc.

Thanks Dave!
Willy




Re: txn:get_headers()

2015-12-14 Thread thierry . fournier
On Mon, 14 Dec 2015 11:49:17 -0800
Hugues Alary  wrote:

> Hi Thierry,
> 
> Here's my haproxy -v: HA-Proxy version 1.6.2 2015/11/03
> 
> Using req_get_headers() worked, but interestingly enough, it doesn't show
> in the txn structure.


Hi,

The Lua object are a little bit complicated. Some component of the
object are accessible in direct, and other one via the metatable.

METATABLE is a special table which allow dynamic members and
inheritance.

Entry "[0]", is the attached C struct (HAProxy convention).

Other entries are "specific" to the object. I mean, that the other
entry were not inherited from the class, but were attached to the
object when it is created.

Between these other entries, we found th entry "http". In the "__index"
of the metatable of this entry, we found "req_get_headers()".

Ok, its not easy ;)

I try to explain the object format in the link below. Its a short
explaination.

   http://www.arpalert.org/haproxy-lua.html#h208

Thierry
   


> And here's the dump:
> 
> (table) HAProxy class TXN [
> METATABLE: (table) table: 0xf8fe70 [
> "__index": (table) table: 0xf80650 [
> "deflog": (function) function: 0x4a58b0
> "log": (function) function: 0x4a5e10
> "Warning": (function) function: 0x4a5a80
> "done": (function) function: 0x4a3c40
> "get_priv": (function) function: 0x4a2490
> "Debug": (function) function: 0x4a5530
> "Info": (function) function: 0x4a56f0
> "Alert": (function) function: 0x4a5370
> "set_var": (function) function: 0x4a3600
> "set_priv": (function) function: 0x4a3440
> "set_tos": (function) function: 0x4a3110
> "set_mark": (function) function: 0x4a3050
> "get_var": (function) function: 0x4a3780
> "set_loglevel": (function) function: 0x4a2cb0
> ]
> "__tostring": (function) function: 0xf805e0
> ]
> 0: (userdata) userdata: 0x10c7c98
> "sc": (table) HAProxy class Converters [
> METATABLE: (table) table: 0xf7c400 [
> "__index": (table) table: 0xf7c4b0 [
> "table_sess_rate": (function) function: 0xf85920
> "hex": (function) function: 0xf86410
> "djb2": (function) function: 0xf86640
> "http_date": (function) function: 0xf85a00
> "table_conn_rate": (function) function: 0xf80a10
> "capture_req": (function) function: 0xf85ae0
> "table_http_req_rate": (function) function: 0xf85bf0
> "table_conn_cnt": (function) function: 0xf85680
> "table_server_id": (function) function: 0xf85d50
> "table_gpt0": (function) function: 0xf85620
> "table_bytes_in_rate": (function) function: 0xf808d0
> "table_kbytes_out": (function) function: 0xf85ce0
> "table_trackers": (function) function: 0xf85990
> "table_sess_cnt": (function) function: 0xf85dc0
> "neg": (function) function: 0xf86150
> "even": (function) function: 0xf860e0
> "language": (function) function: 0xf85a70
> "odd": (function) function: 0xf86070
> "table_http_err_rate": (function) function: 0xf857f0
> "capture_res": (function) function: 0xf86240
> "bool": (function) function: 0xf85fc0
> "base64": (function) function: 0xf86320
> "table_http_err_cnt": (function) function: 0xf85770
> "bytes": (function) function: 0xf85f10
> "ipmask": (function) function: 0xf86480
> "cpl": (function) function: 0xf85f80
> "sdbm": (function) function: 0xf85e30
> "crc32": (function) function: 0xf865d0
> "utime": (function) function: 0xf86560
> "table_gpc0_rate": (function) function: 0xf858e0
> "lower": (function) function: 0xf863a0
> "table_kbytes_in": (function) function: 0xf85c60
> "table_bytes_out_rate": (function) function: 0xf809a0
> "ltime": (function) function: 0xf864f0
> "in_table": (function) function: 0xf80820
> "not": (function) function: 0xf86000
> "wt6": (function) function: 0xf85ea0
> "url_dec": (function) function: 0xf862b0
> "table_conn_cur": (function) function: 0xf856f0
> "table_http_req_cnt": (function) function: 0xf85b70
> "table_gpc0": (function) function: 0xf85870
> "upper": (function) function: 0xf86360
> ]
> "__tostring": (function) function: 0xf7c440
> ]
> 0: (userdata) userdata: 0x10b91d8
> ]
> "req": (table) HAProxy class Channel [
> METATABLE: (table) table: 0xf7c170 [
> "__index": (table) 

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

2015-12-14 Thread Dave Zhu (yanbzhu)
Thank you Willy and Emeric for their efforts in the design, and thanks to
everyone else for all your support and help in testing/debugging this
feature!

I¹ve attached the DOC patch to this message. Please take a look and let me
know if you see any errors in formatting that needs fixed.

-Dave

On 12/14/15, 5:27 AM, "Willy Tarreau"  wrote:

>Hi guys,
>
>On Thu, Dec 10, 2015 at 09:29:57PM +0100, Janusz Dziemidowicz wrote:
>> 2015-12-10 21:14 GMT+01:00 Dave Zhu (yanbzhu) :
>> > Finished OCSP portion. It???s in patch 5
>> >
>> > OCSP staple files will have to be in the same format:
>>haproxy.pem.rsa.ocsp
>> > and haproxy.pem.ecdsa.ocsp. They will get picked up when you load
>> > haproxy.pem in any of the supported methods.
>> >
>> > This patch is slightly bigger, as there was some refactoring that had
>>to
>> > be done to support multi-cert SSL_CTX???s.
>> >
>> > The only remaining piece would be SCTL support, and I have no
>>experience
>> > with that. Someone else will have to step in to add that
>>functionality.
>> 
>> I haven't been following this thread closely, but SCTL should be very
>> similar to OCSP. SCTL stands for signed certificate timestamp list and
>> is just a simple list of signatures from Certificate Transparency
>> logs. This is just a binary blob tied to a given certificate. If the
>> client includes CT extension, then the server should locate apropriate
>> SCTL (haproxy.pem.rsa.sctl or haproxy.pem.ecdsa.sctl) and include it
>> in its initial reply. That's all.
>> 
>> I'll try to take a look at the patch set in the following weekend if I
>> find some time.
>
>I wanted to let you know that I've just merged Dave's work now. Janusz,
>just rebase on latest master, that'll make your work easier. Dave, please
>don't forget to update the documentation :-)
>
>Thanks to all reviewers and testers, that was pretty efficient!
>
>Willy
>



0006-DOC-ssl-Adding-docs-for-Multi-Cert-bundling.patch
Description: 0006-DOC-ssl-Adding-docs-for-Multi-Cert-bundling.patch


Re: Unsubscribe

2015-12-14 Thread Christopher Opena
Is this the proper way to unsubscribe?  I've tried this, sending
unsubscribe to haproxy+unsubscribe, bit neither seem to work.  Might be
good to have this documented somewhere.
On Dec 14, 2015 9:42 AM, "Quan-Ha Le"  wrote:

>
>


Re: lua, changing response-body in http pages 'supported' ?

2015-12-14 Thread thierry . fournier
On Mon, 14 Dec 2015 18:24:21 +0100
Nenad Merdanovic  wrote:

> Hello,
> 
> Sorry for top posting, but has there been any progress in getting the
> ability to rewrite response body with Lua in HAproxy (easy way)? I would
> assume AppletHTTP could be used for this, but I see that http-response
> doesn't support use-service.


Hi Nenad,

The use-service allow HAProxy/Lua to have a HTTP server behaviour. The
Lua executed in a directive use-service receives an http resquest and
sends an http response. In the "use-service" mode, we quit the proxy
mode.

Obvisouly, this mode have no sense with responses.

So, the use-service cannot allow to rewrite the response.

The best way is the non-keepalive requests and the TCP mode. If the
http request uses the connexion close mode, the content-length can be
deleted, and the transfer-enconding chunked too.

In this case, the body can be modified.

In other way, if you want to support the keep-alive, you can try to
write an Lua action which converts received HTTP data from any mode, to
a "transfer-encoding: chunked" mode.

When the data is transfered with chunks, you can manipulate streams
during the tranfer.

This is a little bit complex to write because you must reenconding an
http parser.

Thierry

> Regards,
> Nenad
> 
> On 10/26/2015 12:00 PM, Thierry FOURNIER wrote:
> > On Sun, 25 Oct 2015 02:09:15 +0100
> > PiBa-NL  wrote:
> > 
> >> Hi Thierry, haproxy-list,
> >>
> >> Op 19-10-2015 om 11:24 schreef thierry.fourn...@arpalert.org:
> >>> On Mon, 19 Oct 2015 01:31:42 +0200
> >>> PiBa-NL  wrote:
> >>>
>  Hi Thierry,
> 
>  Op 18-10-2015 om 21:37 schreef thierry.fourn...@arpalert.org:
> > On Sun, 18 Oct 2015 00:07:13 +0200
> > PiBa-NL  wrote:
> >
> >> Hi haproxy list,
> >>
> >> For testing purposes i am trying to 'modify' a response of a webserver
> >> but only having limited success. Is this supposed to work?
> >> As a more usefull goal than the current LAL to TST replacement i 
> >> imagine
> >> rewriting absolute links on a webpage could be possible which is
> >> sometimes problematic with 'dumb' webapplications..
> >>
> >> Or is it outside of the current scope of implemented functionality? If
> >> so, it on the 'lua todo list' ?
> >>
> >> I tried for example a configuration like below. And get several
> >> different results in the browser.
> >> -Sometimes i get 4 times TSTA
> >> -Sometimes i see after the 8th TSTA- Connection: keep-alive << this
> >> happens most of the time..
> >> -Sometimes i get 9 times TSTA + STOP << this would be the desired
> >> outcome (only seen very few times..)
> >>
> >> Probably due to the response-buffer being filled differently due to
> >> 'timing'..
> >>
> >> The "connection: keep-alive" text is probably from the actual server
> >> reply which is 'appended' behind the response generated by my lua
> >> script.?. However shouldn't the .done() prevent that from being send to
> >> the client?
> >>
> >> Ive tried putting a loop into the lua script to call res:get() multiple
> >> times but that didnt seem to work..
> >>
> >> Also to properly modify a page i would need to know all changes before
> >> sending the headers with changed content-length back to the client..
> >>
> >> Can someone confirm this is or isn't (reliably) possible? Or how this
> >> can be scripted in lua differently?
> > Hello,
> >
> > Your script replace 3 bytes by 3 bytes, this must run with HTTP, but if
> > your replacement change the length of the response, you can have some
> > difficulties with clients, or with keepalive.
>  Yes i started with replacing with the same number of bytes to avoid some
>  of the possible troubles caused by changing the length.. And as seen in
>  the haproxy.cfg it is configured with 'mode http'.
> > The res:get(), returns the current content of the response buffer.
> > Maybe it not contains the full response. You must execute a loop with
> > regular "core.yield()" to get back the hand to HAProxy and wait for new
>  Calling yield does allow to 'wait' for more data to come in.. No
>  guarantee that it only takes 1 yield for data to 'grow'..
> 
>  [info] 278/055943 (77431) : luahttpresponse Content-Length XYZ: 14115
>  [info] 278/055943 (77431) : luahttpresponse SIZE: 2477
>  [info] 278/055943 (77431) : luahttpresponse LOOP
>  [info] 278/055943 (77431) : luahttpresponse SIZE: 6221
>  [info] 278/055943 (77431) : luahttpresponse LOOP
>  [info] 278/055943 (77431) : luahttpresponse SIZE: 7469
>  [info] 278/055943 (77431) : luahttpresponse LOOP
>  [info] 278/055943 (77431) : luahttpresponse SIZE: 7469
>  [info] 278/055943 (77431) : luahttpresponse LOOP
>  [info] 278/055943 (77431) : luahttpresponse SIZE: 7469
>  [info] 278/055943 (77431) : luahttpresponse LOOP
>  [info] 278/055943 (77

Unsubscribe

2015-12-14 Thread Quan-Ha Le



Re: lua, changing response-body in http pages 'supported' ?

2015-12-14 Thread Nenad Merdanovic
Hello,

Sorry for top posting, but has there been any progress in getting the
ability to rewrite response body with Lua in HAproxy (easy way)? I would
assume AppletHTTP could be used for this, but I see that http-response
doesn't support use-service.

Regards,
Nenad

On 10/26/2015 12:00 PM, Thierry FOURNIER wrote:
> On Sun, 25 Oct 2015 02:09:15 +0100
> PiBa-NL  wrote:
> 
>> Hi Thierry, haproxy-list,
>>
>> Op 19-10-2015 om 11:24 schreef thierry.fourn...@arpalert.org:
>>> On Mon, 19 Oct 2015 01:31:42 +0200
>>> PiBa-NL  wrote:
>>>
 Hi Thierry,

 Op 18-10-2015 om 21:37 schreef thierry.fourn...@arpalert.org:
> On Sun, 18 Oct 2015 00:07:13 +0200
> PiBa-NL  wrote:
>
>> Hi haproxy list,
>>
>> For testing purposes i am trying to 'modify' a response of a webserver
>> but only having limited success. Is this supposed to work?
>> As a more usefull goal than the current LAL to TST replacement i imagine
>> rewriting absolute links on a webpage could be possible which is
>> sometimes problematic with 'dumb' webapplications..
>>
>> Or is it outside of the current scope of implemented functionality? If
>> so, it on the 'lua todo list' ?
>>
>> I tried for example a configuration like below. And get several
>> different results in the browser.
>> -Sometimes i get 4 times TSTA
>> -Sometimes i see after the 8th TSTA- Connection: keep-alive << this
>> happens most of the time..
>> -Sometimes i get 9 times TSTA + STOP << this would be the desired
>> outcome (only seen very few times..)
>>
>> Probably due to the response-buffer being filled differently due to
>> 'timing'..
>>
>> The "connection: keep-alive" text is probably from the actual server
>> reply which is 'appended' behind the response generated by my lua
>> script.?. However shouldn't the .done() prevent that from being send to
>> the client?
>>
>> Ive tried putting a loop into the lua script to call res:get() multiple
>> times but that didnt seem to work..
>>
>> Also to properly modify a page i would need to know all changes before
>> sending the headers with changed content-length back to the client..
>>
>> Can someone confirm this is or isn't (reliably) possible? Or how this
>> can be scripted in lua differently?
> Hello,
>
> Your script replace 3 bytes by 3 bytes, this must run with HTTP, but if
> your replacement change the length of the response, you can have some
> difficulties with clients, or with keepalive.
 Yes i started with replacing with the same number of bytes to avoid some
 of the possible troubles caused by changing the length.. And as seen in
 the haproxy.cfg it is configured with 'mode http'.
> The res:get(), returns the current content of the response buffer.
> Maybe it not contains the full response. You must execute a loop with
> regular "core.yield()" to get back the hand to HAProxy and wait for new
 Calling yield does allow to 'wait' for more data to come in.. No
 guarantee that it only takes 1 yield for data to 'grow'..

 [info] 278/055943 (77431) : luahttpresponse Content-Length XYZ: 14115
 [info] 278/055943 (77431) : luahttpresponse SIZE: 2477
 [info] 278/055943 (77431) : luahttpresponse LOOP
 [info] 278/055943 (77431) : luahttpresponse SIZE: 6221
 [info] 278/055943 (77431) : luahttpresponse LOOP
 [info] 278/055943 (77431) : luahttpresponse SIZE: 7469
 [info] 278/055943 (77431) : luahttpresponse LOOP
 [info] 278/055943 (77431) : luahttpresponse SIZE: 7469
 [info] 278/055943 (77431) : luahttpresponse LOOP
 [info] 278/055943 (77431) : luahttpresponse SIZE: 7469
 [info] 278/055943 (77431) : luahttpresponse LOOP
 [info] 278/055943 (77431) : luahttpresponse SIZE: 7469
 [info] 278/055943 (77431) : luahttpresponse LOOP
 [info] 278/055943 (77431) : luahttpresponse SIZE: 7469
 [info] 278/055943 (77431) : luahttpresponse LOOP
 [info] 278/055943 (77431) : luahttpresponse SIZE: 7469
 [info] 278/055943 (77431) : luahttpresponse LOOP
 [info] 278/055943 (77431) : luahttpresponse SIZE: 7469
 [info] 278/055943 (77431) : luahttpresponse LOOP
 [info] 278/055943 (77431) : luahttpresponse SIZE: 8717
 [info] 278/055943 (77431) : luahttpresponse LOOP
 [info] 278/055943 (77431) : luahttpresponse SIZE: 14337
 [info] 278/055943 (77431) : luahttpresponse DONE?: 14337

> data. When all the data are read, res:get() returns an error.
 Not sure when/how this error would happen.? The result of res:get only
 seems to get bigger while the webserver is sending the response..
> The res:send() is dangerous because it send data directly to the client
> without the end of haproxy analysis. Maybe it is the cause o your
> problem.
>
> Try to use res:set().
 Ok tried that, new try with function below.
> The difficulty is that another 

RE: question haproxy 1.5

2015-12-14 Thread Lukas Tribus

> Hi Lukas,
>
> We try :
> bind :443 ssl crt /etc/ssl/ : it's doesn't work

Can you elaborate what it doesn't work mean? Does haproxy
refuse to start with an error? If so, please post the exact error
message.

Also post the output of haproxy -vv and confirm that you are
starting haproxy with root privileges.



Thanks,

Lukas

  


RE: question haproxy 1.5

2015-12-14 Thread Labedan, Alain
Hi Lukas,

We try : 
bind :443 ssl crt /etc/ssl/   :   it's doesn't work 

Regards

Alain Labedan 
France GDC | CGI | Centre de Compétences IM France
17 place des Reflets, 92097 Paris la Défense cedex | France- 0157877340

alain.labe...@cgi.com |
 

CGI France SAS 
Capital : 12 913 933 euros | RCS Nanterre 702 042 755 
Siège social : Immeuble CB16 | 17, place des Reflets | 92400 Courbevoie | France

AVIS DE CONFIDENTIALITÉ : Ce message peut contenir des renseignements 
confidentiels appartenant exclusivement au Groupe CGI inc. ou à ses filiales. 
Si vous n'êtes pas le destinataire indiqué ou prévu dans ce message (ou 
responsable de livrer ce message à la personne indiquée ou prévue) ou si vous 
pensez que ce message vous a été adressé par erreur, vous ne pouvez pas 
utiliser ou reproduire ce message, ni le livrer à quelqu'un d'autre. Dans ce 
cas, vous devez le détruire et vous êtes prié d'avertir l'expéditeur en 
répondant au courriel.​

-Message d'origine-
De : Lukas Tribus [mailto:luky...@hotmail.com] 
Envoyé : lundi 14 décembre 2015 15:16
À : Labedan, Alain; haproxy@formilux.org
Objet : RE: question haproxy 1.5

Hi Alain,


> We try 
> Bind :443 ssl crt /etc/ssl : but without success . 
> 
> Or 
> Bind :443 ssl crt /etc/ssl/*.pem : but without success 

Try:
bind :443 ssl crt /etc/ssl/

with the slash at the end.



Regards,

Lukas

  


RE: question haproxy 1.5

2015-12-14 Thread Lukas Tribus
Hi Alain,


> We try 
> Bind :443 ssl crt /etc/ssl : but without success . 
> 
> Or 
> Bind :443 ssl crt /etc/ssl/*.pem : but without success 

Try:
bind :443 ssl crt /etc/ssl/

with the slash at the end.



Regards,

Lukas

  

question haproxy 1.5

2015-12-14 Thread Labedan, Alain
Hi,

For the front-end in https, we have several clients, so several certificates as 
in the exemple below.
..
Mode http
Bind :443 ssl crt /etc/ssl/certificate1.pem  crt 
/etc/ssl/certificate2.pem  crt ….

But we want to declare a folder for the certificates .

We try
Bind :443 ssl crt /etc/ssl  :   but without success .
Or
Bind :443 ssl crt /etc/ssl/*.pem:   but without success .

Bests regards

Cordialement,

Alain Labedan
France GDC | CGI | Centre de Compétences IM France
17 place des Reflets, 92097 Paris la Défense cedex | France- 0157877340

alain.labe...@cgi.com |
 [Description : environment-logo-email]
[Description : CGI_Logo2012_color.png]
CGI France SAS
Capital : 12 913 933 euros | RCS Nanterre 702 042 755
Siège social : Immeuble CB16 | 17, place des Reflets | 92400 Courbevoie | France

AVIS DE CONFIDENTIALITÉ : Ce message peut contenir des renseignements 
confidentiels appartenant exclusivement au Groupe CGI inc. ou à ses filiales. 
Si vous n'êtes pas le destinataire indiqué ou prévu dans ce message (ou 
responsable de livrer ce message à la personne indiquée ou prévue) ou si vous 
pensez que ce message vous a été adressé par erreur, vous ne pouvez pas 
utiliser ou reproduire ce message, ni le livrer à quelqu'un d'autre. Dans ce 
cas, vous devez le détruire et vous êtes prié d'avertir l'expéditeur en 
répondant au courriel.​



Re: SSL backend with ssl passthrough and client cert

2015-12-14 Thread Idar Borlaug
Ah ok, thanks.

Now it works, client privatekey and the certificate i sent to the server in
client.pem

check and ssl-check parameter on serverline.

On Mon, Dec 14, 2015 at 2:14 PM Lukas Tribus  wrote:

> Hi,
>
>
> > In the client.pem file i put the servers certificate and the client
> > private key, do i need to put the client certificate also in that file?
>
> You *don't* put the server certificate in that file at all. Its wrong to do
> so and it will never work that way.
>
> You put:
> - the client certificate
> - the corresponding private key of the client certificate
>
> in the client.pem file that you point to with the crt keyword.
>
>
>
> Regards,
>
> Lukas
>
>

-- 
Idar Borlaug


RE: SSL backend with ssl passthrough and client cert

2015-12-14 Thread Lukas Tribus
Hi,


> In the client.pem file i put the servers certificate and the client
> private key, do i need to put the client certificate also in that file?

You *don't* put the server certificate in that file at all. Its wrong to do
so and it will never work that way.

You put:
- the client certificate
- the corresponding private key of the client certificate

in the client.pem file that you point to with the crt keyword.



Regards,

Lukas

  


Re: SSL backend with ssl passthrough and client cert

2015-12-14 Thread Idar Borlaug
I have one privatekey which the server has a public key  version of in its
truststore.
And i have the servers publickey/certificate in my truststore.

In the client.pem file i put the servers certificate and the client private
key, do i need to put the client certificate also in that file?

In my java client, i have the server certificate in a truststore, and my
privatekey in a keystore.



On Mon, Dec 14, 2015 at 1:59 PM Lukas Tribus  wrote:

> Hi Idar,
>
>
>
> > If i put my client-key in client.pem then i get this error: unable to
> > load ssl certificate from PEM file
>
> The crt keyword [1] in the backend configuration expects both the
> client certificate and the corresponding (client-cert) private-key.
>
>
> > When i use my java client i only need the server certificate and my
> > private key.
>
> You meant the *client* certificate and its private key, correct?
>
> You need to do the same for haproxy (concatenating client cert with
> the private key).
>
>
>
> Regards,
>
> Lukas
>
>
>
> [1] http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.2-crt
>

-- 
Idar Borlaug


RE: SSL backend with ssl passthrough and client cert

2015-12-14 Thread Lukas Tribus
Hi Idar,



> If i put my client-key in client.pem then i get this error: unable to 
> load ssl certificate from PEM file 

The crt keyword [1] in the backend configuration expects both the
client certificate and the corresponding (client-cert) private-key.


> When i use my java client i only need the server certificate and my 
> private key. 

You meant the *client* certificate and its private key, correct?

You need to do the same for haproxy (concatenating client cert with
the private key).



Regards,

Lukas



[1] http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.2-crt
  



Re: SSL backend with ssl passthrough and client cert

2015-12-14 Thread Idar Borlaug
If i put my client-key in client.pem then i get this error: unable to load
ssl certificate from PEM file

Is i also put the server certificate in client.pem i get this
error: inconsistencies between private key and certificate loaded from PEM
file

When i use my java client i only need the server certificate and my private
key.



On Mon, Dec 14, 2015 at 12:55 PM Lukas Tribus  wrote:

> > Hi
> >
> > I am trying to set up haproxy with tcp mode for passing through ssl
> > connection. But i want to check my backend health with http call.
> > My backend requiers the use of a client key.
> >
> > I tried something like this:
> > option httpchk GET /status HTTP/1.0\r\nHost:\ localhost
> > server backend1 backend1:8900 check ssl verify none crt
> > /etc/haproxy/client-key.pem
>
> Don't use:
> check ssl
>
> it will enable SSL for all the traffic, not only for health checks.
>
> You wan't:
> check-ssl
>
> which enables SSL only for the health checks
> (since your passing through TCP without intercepting
> SSL).
>
>
>
>
> Regards,
>
> Lukas
>
>

-- 
Idar Borlaug


RE: SSL backend with ssl passthrough and client cert

2015-12-14 Thread Lukas Tribus
> Hi 
> 
> I am trying to set up haproxy with tcp mode for passing through ssl 
> connection. But i want to check my backend health with http call. 
> My backend requiers the use of a client key. 
> 
> I tried something like this: 
> option httpchk GET /status HTTP/1.0\r\nHost:\ localhost 
> server backend1 backend1:8900 check ssl verify none crt 
> /etc/haproxy/client-key.pem 

Don't use:
check ssl

it will enable SSL for all the traffic, not only for health checks.

You wan't:
check-ssl

which enables SSL only for the health checks
(since your passing through TCP without intercepting
SSL).




Regards,

Lukas

  


SSL backend with ssl passthrough and client cert

2015-12-14 Thread Idar Borlaug
Hi

I am trying to set up haproxy with tcp mode for passing through ssl
connection. But i want to check my backend health with http call.
My backend requiers the use of a client key.

I tried something like this:
option httpchk GET /status HTTP/1.0\r\nHost:\ localhost
server backend1 backend1:8900 check ssl verify none crt
/etc/haproxy/client-key.pem

I am then getting an error that client-key.pem dosen't contain a
certificate, if i add the truststore certificates to client-key.pem i get
inconsistency.

Is it possible to run this check with client key? How do i configure it?
-- 
Idar Borlaug


Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

2015-12-14 Thread Willy Tarreau
Hi guys,

On Thu, Dec 10, 2015 at 09:29:57PM +0100, Janusz Dziemidowicz wrote:
> 2015-12-10 21:14 GMT+01:00 Dave Zhu (yanbzhu) :
> > Finished OCSP portion. It???s in patch 5
> >
> > OCSP staple files will have to be in the same format: haproxy.pem.rsa.ocsp
> > and haproxy.pem.ecdsa.ocsp. They will get picked up when you load
> > haproxy.pem in any of the supported methods.
> >
> > This patch is slightly bigger, as there was some refactoring that had to
> > be done to support multi-cert SSL_CTX???s.
> >
> > The only remaining piece would be SCTL support, and I have no experience
> > with that. Someone else will have to step in to add that functionality.
> 
> I haven't been following this thread closely, but SCTL should be very
> similar to OCSP. SCTL stands for signed certificate timestamp list and
> is just a simple list of signatures from Certificate Transparency
> logs. This is just a binary blob tied to a given certificate. If the
> client includes CT extension, then the server should locate apropriate
> SCTL (haproxy.pem.rsa.sctl or haproxy.pem.ecdsa.sctl) and include it
> in its initial reply. That's all.
> 
> I'll try to take a look at the patch set in the following weekend if I
> find some time.

I wanted to let you know that I've just merged Dave's work now. Janusz,
just rebase on latest master, that'll make your work easier. Dave, please
don't forget to update the documentation :-)

Thanks to all reviewers and testers, that was pretty efficient!

Willy




[SPAM] LED Highbay light can reach 120-130lm

2015-12-14 Thread better led

	Dear  Sir 
	
	we have new LED Highbay light.  130lm/w,use PHILIPS LED and MW driver, with very competitive price.
	I think it must be helpful for you
	
	pls see beow:  
	
	
	
	
	Peter Tang
	
	Sales Manager
	Shanghai Leiqiong Lighting Technology Co.,ltd
	T: 86 021 52716052 | | F: 86 021 52716053
	E: petertang@better-led.com
	Skype: kuanglong49


FW: haproxy log

2015-12-14 Thread Cohen Galit
Hello!

Can you examine the logger below?
I'm afraid I have a configuration problem in haproxy config, maybe in one of 
the timeout limits.
These lines are printed only after load tests are starting to  fail over tcp 
against 5 imap servers round robin.

We are load testing over than  1M create sockets.

Here is the configuration:

global
log 127.0.0.1  local0 debug  #emerg  alert  crit   errwarning 
notice info  debug
maxconn 90096
tune.ssl.default-dh-param 2048
uid 55301
   gid 55301

defaults
logglobal
modetcp
option tcplog
option dontlognull
retries 3
maxconn 90096
timeout client 60
timeout server 6
timeout connect 5000

listen HAProxy_VVM
log global
option tcplog
mode tcp
bind :50143 name VVM_PLAIN
bind :50443 name VVM_SSL
   #bind :50993 name VVM_TLS
balance roundrobin
#option tcp-check
#tcp-check connect port 50443 ssl  # USED FOR MIST VVM HEALTH CHECK. DO 
NOT COMMENT OR CHANGE THIS LINE.
#tcp-check expect string *\ OK
maxconn 90096
timeout client 60
timeout server 12
timeout connect 5000
#server mips 10.45.92.35 check verify none inter 3
server cas-au53 10.106.75.53 check verify none inter 3
server cas-au61 10.106.75.61 check verify none inter 3
server cas-au62 10.106.75.62 check verify none inter 3
server cas-au63 10.106.75.63 check verify none inter 3
server cas-au132 10.106.138.132 check verify none inter 3



Thanks,
Galit

From: Kuterman Itzik
Sent: Sunday, December 13, 2015 12:09 PM
To: Cohen Galit
Subject: haproxy log?


Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.146:34747 
[13/Dec/2015:10:55:05.698] HAProxy_VVM HAProxy_VVM/cas-au53 1/0/ 966 -- 
447/447/447/88/0 0/0
Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.163:63043 
[13/Dec/2015:10:55:05.751] HAProxy_VVM HAProxy_VVM/cas-au63 1/0/ 966 -- 
445/445/445/89/0 0/0
Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.163:63043 
[13/Dec/2015:10:55:05.751] HAProxy_VVM HAProxy_VVM/cas-au63 1/0/ 966 -- 
445/445/445/89/0 0/0
Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.166:49649 
[13/Dec/2015:10:55:05.807] HAProxy_VVM HAProxy_VVM/cas-au53 1/0/10004 966 -- 
443/443/443/88/0 0/0
Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.166:49649 
[13/Dec/2015:10:55:05.807] HAProxy_VVM HAProxy_VVM/cas-au53 1/0/10004 966 -- 
443/443/443/88/0 0/0
Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.162:14719 
[13/Dec/2015:10:55:05.923] HAProxy_VVM HAProxy_VVM/cas-au61 1/0/9998 1239 -- 
442/442/442/88/0 0/0
Dec 13 10:55:15 localhost.localdomain haproxy[11803]: 10.106.161.162:14719 
[13/Dec/2015:10:55:05.923] HAProxy_VVM HAProxy_VVM/cas-au61 1/0/9998 1239 -- 
442/442/442/88/0 0/0
Dec 13 10:55:16 localhost.localdomain haproxy[11803]: 10.106.161.164:17564 
[13/Dec/2015:10:55:06.025] HAProxy_VVM HAProxy_VVM/cas-au63 1/0/ 1238 -- 
443/443/443/89/0 0/0
Dec 13 10:55:16 localhost.localdomain haproxy[11803]: 10.106.161.164:17564 
[13/Dec/2015:10:55:06.025] HAProxy_VVM HAProxy_VVM/cas-au63 1/0/ 1238 -- 
443/443/443/89/0 0/0
Dec 13 10:55:16 localhost.localdomain haproxy[11803]: 10.106.161.164:17565 
[13/Dec/2015:10:55:06.032] HAProxy_VVM HAProxy_VVM/cas-au132 1/0/ 1239 -- 
443/443/443/89/0 0/0


"This e-mail message may contain confidential, commercial or privileged 
information that constitutes proprietary information of Xura, Inc. or its 
subsidiaries. If you are not the intended recipient of this message, you are 
hereby notified that any review, use or distribution of this information is 
absolutely prohibited and we request that you delete all copies and contact us 
by e-mailing to: secur...@xura.com. Thank You."


Re: Lua plugin for Let's Encrypt CA available

2015-12-14 Thread Thierry FOURNIER
On Sun, 13 Dec 2015 17:21:51 +0100
"Jan A. Bruder"  wrote:

> Thought i should put the Lua API to some good use: The plugin introduces
> support for ACME domain validation against running instances of HAProxy.
> 
> https://github.com/janeczku/haproxy-acme-validation-plugin

Hi,

Thank you for the share. I guess than let's encrypt will be
very used in the next month, and this plugin will be very useful.

It uses a fil system acces, and the HAProxy design doesn't support
these type of blocking access.

If I understand, the goal is to store a lot of file named with a token
value, and containing a challenge which will be returned on the http
response.

Maybe these token can be stored on a ramdisk (like /dev/shm), or you
can use and tcp access to a ligth database like redis.

Thierry



Re: txn:get_headers()

2015-12-14 Thread Thierry FOURNIER
On Fri, 11 Dec 2015 17:05:16 -0800
Hugues Alary  wrote:

> Hi there,
> 
> I'm trying my hands on haproxy 1.6.2 and I'm excited about the LUA
> integration.
> 
> I'm however running into an issue and can't figure out why. Please forgive
> me if my issue is only due to my complete ignorance about LUA (I literally
> just opened the language documentation).
> 
> I'm trying to call the txn:get_headers() function, but when doing so, I get
> the following error in my logs: "Lua function 'myFunc': runtime error:
> /etc/haproxy/hello_world.lua:2: attempt to call a nil value (method
> 'get_headers')."


Hi,

This is strange: Lua says that you try to "call a nil value" when you
try to execute a funciton which doesn't exists.

In your case, the fucntion exists. You can dump the full stuct of the
"txn" var with the function below:

   http://ww.arpalert.org/haproxy-scripts.html#print_r

Just add "print_r(txn)", and you will be fixed about the content of the
object "txn".

I read the haproxu luacode to be sure of the existence of these
function, and I sew that it was renamed. So, try the function:

   req_get_headers()

The API doc:

   http://www.arpalert.org/src/haproxy-lua-api/1.7dev/#txn-class

Thierry.


> function myFunc(txn)
>   txn:get_headers()
> end
> 
> core.register_action("myFunc", { "http-req" }, myFunc);
> 
> Is this a bug, or just me not knowing what I'm doing?
> 
> It's worth noting that calling: txn:done() works.
> 
> Sincerely,
> -Hugues



high end places'best choice-led mini recessed spotlight kits

2015-12-14 Thread june
DearPurchasemanager,  =;  
2016upgradedledminirecesseddownlightreleased.with=thefollowingfeatures: 
 =;1)Epistarledchips,95lm*6pcs  =;2)2700-5000Koption 
 =;3)outputvoltage:12VDC-24VDC  =;4)weatherproofgrade:IP64 
 =;5)CRI>80   bestwishesJunewww.sunriseleds.com