Re: Using haproxy together with NFS

2018-08-01 Thread Lucas Rolff
Hi michael,

Without the send-proxy, the client IP in the export would have to be the 
haproxy server in that case right?

The issue there is then, that I end up with all clients having access to 
haproxy can suddenly mount all shares in nfs, which I would like to prevent

There’s still different shares that different servers need access to

I’ll try not the sample config from the link above! Thanks!

Get Outlook for iOS

From: Michael Ezzell 
Sent: Thursday, August 2, 2018 2:38:06 AM
To: Lucas Rolff
Cc: HAproxy Mailing Lists
Subject: Re: Using haproxy together with NFS



On Wed, Aug 1, 2018, 16:00 Lucas Rolff 
mailto:lu...@lucasrolff.com>> wrote:

I use the “send-proxy” to let the NFS Server see the actual source IP, instead 
of the haproxy machine IP.
You'll probably need remove that.  Unless the destination service explicitly 
supports the Proxy Protocol (in which case, it must not, by definition, process 
connections where the protocol's preamble is *absent* from the stream), then 
this would just look like corrupt data.  This option doesn't actually change 
the source address.

HAProxy in TCP mode should work fine with NFS -- at least, it does with NFS4.1 
as implemented in Amazon Elastic File System -- which is the only version I've 
tested against.

https://serverfault.com/a/799213/153161




Re: Using haproxy together with NFS

2018-08-01 Thread Michael Ezzell
On Wed, Aug 1, 2018, 16:00 Lucas Rolff  wrote:

>
> I use the “send-proxy” to let the NFS Server see the actual source IP,
> instead of the haproxy machine IP.
>
You'll probably need remove that.  Unless the destination service
explicitly supports the Proxy Protocol (in which case, it must not, by
definition, process connections where the protocol's preamble is *absent*
from the stream), then this would just look like corrupt data.  This option
doesn't actually change the source address.

HAProxy in TCP mode should work fine with NFS -- at least, it does with
NFS4.1 as implemented in Amazon Elastic File System -- which is the only
version I've tested against.

https://serverfault.com/a/799213/153161


Using haproxy together with NFS

2018-08-01 Thread Lucas Rolff
Hi guys,

I’ve been playing around today with two NFS servers (each on their own storage 
array), synced by Unison to provide a bit higher uptime.

To allow NFS clients to use a single IP, I’ve configured an haproxy install (1 
now, two when in prod), where I want to talk over tcp mode to the NFS servers.
My idea is that all traffic is directed based on the source IP balancing, so 
the traffic will be somewhat 50/50 on each NFS server.

My question is if anyone have actually ever got a setup like this to work, I’m 
using NFS 4.0, and whenever I try to mount the NFS mount on the client, it does 
communicate with haproxy, and I do see traffic on the NFS server itself, 
meaning the communication seems to work.

The issue I’m facing, is that the mounting will actually never complete due to 
some weird behavior when I go through haproxy:

Aug 01 21:44:44 nfs-server-f8209dc4-a1a6-4baf-86fa-eba0b0254bc9 kernel: RPC: 
fragment too large: 1347571544
Aug 01 21:44:44 nfs-server-f8209dc4-a1a6-4baf-86fa-eba0b0254bc9 kernel: RPC: 
fragment too large: 1347571544
Aug 01 21:44:44 nfs-server-f8209dc4-a1a6-4baf-86fa-eba0b0254bc9 kernel: RPC: 
fragment too large: 1347571544
Aug 01 21:44:45 nfs-server-f8209dc4-a1a6-4baf-86fa-eba0b0254bc9 kernel: RPC: 
fragment too large: 1347571544

It will continue to give this “fragment too large”.
If I bypass haproxy it works completely fine, so I know the NFS Server is 
configured correctly for the client to connect.

My haproxy configuration looks like this:

global
  log 127.0.0.1 local1 debug
  nbproc 4
  user haproxy
  group haproxy
  daemon
  chroot /var/lib/haproxy
  pidfile /var/run/haproxy.pid

defaults
mode tcp
log global
option tcplog
timeout client 1m
timeout server 1m
timeout connect 10s
balance source

frontend nfs-in1
bind *:2049
use_backend nfs_backend1
frontend nfs-in2
bind *:111
use_backend nfs_backend2
frontend nfs-in3
bind *:46716
use_backend nfs_backend3
frontend nfs-in4
bind *:36856
use_backend nfs_backend4

backend nfs_backend1
  server nfs1 217.xx.xx.xx:2049 send-proxy
backend nfs_backend2
  server nfs1 217.xx.xx.xx:111 send-proxy
backend nfs_backend3
  server nfs1 217.xx.xx.xx:46716 send-proxy
backend nfs_backend4
  server nfs1 217.xx.xx.xx:36856 send-proxy

I use the “send-proxy” to let the NFS Server see the actual source IP, instead 
of the haproxy machine IP.

If anyone has any idea what can be the cause of the “fragment too large” when 
going via haproxy, or an actual working config for haproxy to do NFS 4.0 or 4.1 
traffic – then please let me know!

Best Regards,
Lucas Rolff


Re: Possibility to modify PROXY protocol header

2018-08-01 Thread bjun...@gmail.com
2018-07-31 17:56 GMT+02:00 James Brown :
> I think if you use the `http-request set-src` directive it'll populate the
> PROXY headers in addition to the internal logging 
>
> On Fri, Jul 27, 2018 at 7:05 AM bjun...@gmail.com  wrote:
>>
>> Hi,
>>
>> is there any possibilty to modify the client ip in the PROXY Protocol
>> header before it is send to a backend server?
>>
>> My use case is a local integration/functional testing suite (multiple
>> local docker containers for testing the whole stack - haproxy, cache layer,
>> webserver, etc.).
>>
>> I would like to test functionalities which are dependent of/need specific
>> IP ranges or IP addresses.
>>
>> 
>> Best Regards / Mit freundlichen Grüßen
>>
>> Bjoern
>
>
>
> --
> James Brown
> Engineer

Hi James,


thanks, that worked like a charm. Didn't know that "set-src" works in
combination with PROXY protocol.



Best Regards / Mit freundlichen Grüßen

Bjoern



Re: Bug when passing variable to mapping function

2018-08-01 Thread Jarno Huuskonen
Hi,

On Tue, Jul 17, Emeric Brun wrote:
> > On Fri, 29 Jun 2018 at 07:15, Jarno Huuskonen  
> > wrote:
> >> On Thu, Jun 28, Jarno Huuskonen wrote:
> >>> I think this is the commit that breaks map_regm in this case:
> >>> b5997f740b21ebb197e10a0f2fe9dc13163e1772 (MAJOR: threads/map: Make
> >>> acls/maps thread safe).
> >>>
> >>> If I revert this commit from pattern.c:pattern_exec_match
> >>> then the map_regm \1 backref seems to work.
> >>
> >> I think I found what's replacing the \000 as first char:
> >> in (map.c) sample_conv_map:
> >> /* In the regm case, merge the sample with the input. */
> >> if ((long)private == PAT_MATCH_REGM) {
> >> str = get_trash_chunk();
> >> str->len = exp_replace(str->str, str->size, 
> >> smp->data.u.str.str,
> >>pat->data->u.str.str,
> >>(regmatch_t *)smp->ctx.a[0]);
> >>
> >> Before call to get_trash_chunk() smp->data.u.str.str is for example
> >> 'distri.com' and after get_trash_chunk() smp->data.u.str.str
> >> is '\000istri.com'.
> 
> Could you try the patch in attachment? i hope it will fix the issue

Sorry I've been away from keyboard. Just tested the patch w/1.8.12 and
for me the patch fixes the map_regm issue with Daniel's example config
(https://www.mail-archive.com/haproxy@formilux.org/msg30523.html).

Thanks,
-Jarno

-- 
Jarno Huuskonen



Re: Performance of using lua calls for map manipulation on every request

2018-08-01 Thread Thierry Fournier
Hi,

The Lua overhead is very low. On my laptop I reach easyly 18 000 HTTP
requests by seconds with basic Lua processing. I guess that your code
will not have significant impact on perfs.

Note that the function:

> txn.http:req_get_headers()["host"][0]

Is consume more CPU than 

   txn.f[‘req.fhdr’](‘host’)

or

   txn.sf[‘req.fhdr’](‘host’)

Other point: I’m not sure that the split() function exists.

Thierry


> On 27 Jul 2018, at 14:38, Sachin Shetty  wrote:
> 
> Hi,
> 
> We are doing about 10K requests/minute on a single haproxy server, we have 
> enough CPUs and memory. Right now each requests looks up a map for backend 
> info. It works well. 
> 
> Now we  need to build some expire logic around the map. Like ignore some 
> entries in the map entries after some time. I could do this in lua, but it 
> woud mean that every request would make a lua call to look up a map value and 
> make a decision.
> 
> My lua method looks like this:
> 
> function get_proxy_from_map(txn)
> local host = txn.http:req_get_headers()["host"][0]
> local value = proxy_map_v2:lookup(host)
> if value then
> local values = split(value, ",")
> local proxy = values[1]
> local time = values[2]
> if os.time() > tonumber(time) then
> core.Alert("Expired: returning nil: " .. host)
> return
> else
> return proxy
> end
> end
> return
> end
> 
> 
> Any suggestions on how this would impact performance, our tests looks ok. 
> 
> Thanks
> Sachin