Re: [Gluster-users] NFS Ganesha HA w/ GlusterFS

[TomK]

On 2/26/2018 7:14 AM, Kaleb S. KEITHLEY wrote:
Hey,

Yep. A blog is where I was writing it up to begin with.

Anyway, got alot of demand for it over the last one day so here it is:

http://microdevsys.com/wp/glusterfs-configuration-and-setup-w-nfs-ganesha-for-an-ha-nfs-cluster/

Skip to the SUMMARY and TESTING sections so you can just copy and paste 
the configs to get things moving very quickly.  The detailed section is 
my running log of all the troubleshooting and failed attempts.


FreeIPA is being used as the DNS / Kerberos backend to which these NFS 
servers will be configured to.  Not yet done with this piece so not yet 
including that mailing list here.


Feel free to point anything out as I would like to keep it accurate.

The post includes all work needed for firewalld and selinux on CentOS 7 
without turning off either service.


Again, thanks for all the help here.  Couldn't get this working without 
all the work you guy's do!


Cheers,
Tom



On 02/25/2018 08:29 PM, TomK wrote:

Hey Guy's,

A success story instead of a question.

With your help, managed to get the HA component working with HAPROXY and
keepalived to build a fairly resilient NFS v4 VM cluster.  ( Used
Gluster, NFS Ganesha v2.60, HAPROXY, keepalived w/ selinux enabled )

If someone needs or it could help your work, please PM me for the
written up post or I could just post here if the lists allow it.



Hi,

I strongly encourage you to write a blog post about it. And if not that
at least write about it and post it to the list(s).

I'm not sure why your post to nfs-ganesha-support was blocked. Maybe
it's waiting for some moderator attention. (But I don't believe that
list is moderated.)

Thanks for sharing.




--
Cheers,
Tom K.
-

Living on earth is expensive, but it includes a free trip around the sun.

Maximum value for inter parameter?

[Nikhil Kapoor]

Hi

Please respond to the query on discourse:
https://discourse.haproxy.org/t/maximum-value-for-inter-parameter/2142

Thanks
Nikhil Kapoor

Re: [PATCH] BUG/MINOR: h2: Set the target of dbuf_wait to h2c

[Willy Tarreau]

Hi Christopher,

On Mon, Feb 26, 2018 at 02:06:20PM +0100, Christopher Faulet wrote:
> Hi Willy,
> 
> Here is a small patch to fix an annoying bug when demux buffer allocation
> fails in H2.

Good catch, shame on me on this one!

Willy

Re: BUG/MINOR: dns: false positive downgrade of accepted_payload_size

[Baptiste]

On Thu, Feb 22, 2018 at 2:04 AM, Lukas Tribus  wrote:

> Hello Baptiste,
>
>
>
> On 21 February 2018 at 19:59, Lukas Tribus  wrote:
> > Baptiste, I don't think you'd find the symptoms I have in mind
> > acceptable on a load-balancer, so there has to be a misunderstanding
> > here. I would like to do some tests, maybe I can come up with a simple
> > testcase that shows the behavior and then we can review the situation
> > based on that testcase; I will probably need a few days for this
> > though.
>
> So this is what I did: I pulled current haproxy master (5e64286bab)
> and applied your patch on top of it. I also added "hold obsolete 30s"
> to the configuration in all those tests.
>
>
> Two things that I noticed:
> - GoogleDNS and recent Bind instances (and probably many others) don't
> actually truncate the response; they don't add any A records to the
> response when they set TC - so the TC response is not incomplete but
> actually completely empty (repro: use testcase vs 8.8.8.8 max payload
> 1280)
> - OpenDNS (208.67.222.222) actually truncates the response (just like
> old bind instances), however haproxy is unable to parse that response,
> so a TC response from OpenDNS is always rejected (repro: use testcase
> vs 208.67.222.222 max payload 1280)
>
> So surprisingly enough in both of those 2 cases, the "auto-downgrade"
> does not reduce the amount of servers in the backend, instead it kills
> the backend completely. With your patch and with "hold obsolete 30s"
> of course.
>
> What I was actually looking for is a testcase that reduces the amount
> of servers in the backend, but I guess that would require a DNS server
> that actually truncates the reply "old-style" and at the same time
> does not cause haproxy do reject the response, but I don't know what
> haproxy doesn't like about the OpenDNS TC response.
>
>
> Back to the original testcase though:
> - testcase config attached
> - "100_pointing_to.localhost.ltri.eu" returns 100 A records in the
> localhost range, it requires aprox. 1600 byte in payload size
> - we can trigger the "auto-downgrade" very easily by shortly
> interrupting DNS traffic via a iptables rule (iptables -A INPUT -i
> eth0 -s 8.8.8.8 -j DROP && sleep 10 && iptables -D INPUT -i eth0 -s
> 8.8.8.8 -j DROP)
> - after we triggered the auto-downgrade, haproxy does not recover and
> no backend servers will be alive, until we reload
>
>
> Auto-downgrade behaves exactly as expected in our previous
> conversation. The exact end-result depends on the behavior of the DNS
> server. But none of those cases are desirable:
>
> Case 1 (Testcase Google DNS, recent Bind):
> - when auto-downgrade fires the response will be TC without any
> records; Haproxy will disable all servers and the entire backend will
> be down (fix: restart haproxy)
>
> Case 2 (Testcase OpenDNS):
> - when auto-downgrade fires the response will be TC, which haproxy is
> unable to parse;  Haproxy will disable all servers and the entire
> backend will be down (fix: restart haproxy)
>
> Case 3 (assumption based on what ASA on discourse reports, likely old
> Bind):
> - when auto-downgrade fires and the response is TC, TC is ignored
> which means the reply is considered, downgrading the number of servers
> in the backend to a lower number (whatever fitted in the 1280 reply),
> which most likely will overload the existing backend servers (after
> all, there is probably a reason a certain number of servers is in the
> DNS)
>
>
> "hold obsolete" can only help if haproxy is able to recover; but the
> auto-downgrade makes sure no future DNS requests works as expected so
> whatever value "hold obsolete" is set to, once "hold obsolete" is
> over, the problem will show up.
>
>
> Lets talk about the likelihood of an admin configuring a payload size
> above 1280: I think its safe to assume that this is configured based
> on actual needs, so an admin would hit one of the 3 cases above,
> unless I'm missing something. I completely fail to understand the
> benefit of this feature in haproxy.
>
>
> So based on this tests and cases, I would ask you again to consider
> removing this altogether.
>
>
>
> cheers,
> lukas
>


Hi Lukas,

(I was off last week with limited mail access)

First, thanks a lot for all your testing!

Your use case is right and I perfectly understand it and it makes sense to
me.
that said, in my use case, I was using (and meaning) SRV records and using
consul / kubernetes as backend servers.
What I saw is that when the response is too big, the server will send only
the SRV records with TC flag and no "ADDITIONAL" section. So in such case,
it was still acceptable for HAProxy.

According to you, what would be the best option:
- entirely remove this "feature" and consider the admins know what they do
(I include the copy/paste admins that simply copy content of different blog
articles until "it works")
- enable this feature for a single "retry" of the same query? (that would
happen after we did a 

RE: Re: haproxy tcp mode source ip

[Tom Maher]

Thanks Aaron. Our specific purpose is slightly different, and our network 
topology means TPROXY doesn't work for us.

Regards,
Tom

-Original Message-
From: Aaron West 
Sent: 26 February 2018 13:28
To: mingbei...@baifendian.com
Cc: Wang Bin ; haproxy 
Subject: Re: Re: haproxy tcp mode source ip

Hi,

The TPROXY method truly makes it source IP transparent(Your real servers will 
see the connection as coming from the client's IP) so it will be fine for IP 
based privileges I think.

Aaron West

Loadbalancer.org Ltd.

https://emea01.safelinks.protection.outlook.com/?url=www.loadbalancer.org=02%7C01%7Ctom.maher%40asavie.com%7C0819222860dd4502ef1108d57d1cf8a2%7Cff38a05d2e5248389b077fbd50bbae9f%7C0%7C0%7C636552485746274781=eH1QWuLPjlsyf5s7nuoDDnrwyjmXEOyXvRJ4AXYT8IQ%3D=0

+1 888 867 9504 / +44 (0)330 380 1064
aa...@loadbalancer.org

LEAVE A REVIEW | DEPLOYMENT GUIDES | BLOG

The message together with any files transmitted with it are intended solely for 
the use of the individual or entity to whom it is addressed. It may contain 
confidential, proprietary or privileged information. If you are not the 
intended recipient you are hereby notified that: (i) direct or indirect 
disclosure, copying, printing, distribution and/or taking any action in 
reliance on the contents of this message, including any files transmitted with 
it, is strictly prohibited and may be unlawful; and (ii) you should not 
disseminate, distribute or copy this message and/or any files transmitted with 
it. If you have received this message in error, please notify the sender 
immediately and then delete it, and any copies of it, from your system. Asavie 
Technologies Limited, Asavie Technologies, Inc and Asavie Technologies Sales 
Limited (together known as “Asavie Technologies”) reserve the right to monitor 
all e-mail communications through its networks. WARNING: Computer viruses can 
be transmitted via e-mail. You should check this e-mail and any files 
transmitted with it for the presence of computer viruses. Asavie Technologies 
cannot guarantee that this e-mail and any files transmitted with it are free of 
computer viruses. Asavie Technologies accepts no liability for any loss and/or 
damage caused by any computer virus transmitted by this e-mail and/or by any 
files transmitted with it. E-mail transmission cannot be guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete. Asavie Technologies does not accept 
liability for any errors or omissions in the contents of this message, and/or 
any files transmitted with it, which arise as a result of e-mail transmission.

Re: Re: haproxy tcp mode source ip

[Aaron West]

Hi,

The TPROXY method truly makes it source IP transparent(Your real
servers will see the connection as coming from the client's IP) so it
will be fine for IP based privileges I think.

Aaron West

Loadbalancer.org Ltd.

www.loadbalancer.org

+1 888 867 9504 / +44 (0)330 380 1064
aa...@loadbalancer.org

LEAVE A REVIEW | DEPLOYMENT GUIDES | BLOG

[PATCH] BUG/MINOR: h2: Set the target of dbuf_wait to h2c

[Christopher Faulet]

Hi Willy,

Here is a small patch to fix an annoying bug when demux buffer 
allocation fails in H2.


--
Christopher Faulet
>From ccf62f1411d64654b6249d28b1f0b89763bbedbb Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Mon, 26 Feb 2018 13:43:38 +0100
Subject: [PATCH] BUG/MINOR: h2: Set the target of dbuf_wait to h2c

In h2_get_dbuf, when the buffer allocation was failing, dbuf_wait.target was
errornously set to the connection (h2c->conn) instead of the h2 connection
descriptor (h2c).

This patch must be backported to 1.8.
---
 src/mux_h2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mux_h2.c b/src/mux_h2.c
index 9b42d7bbe..de05ca04a 100644
--- a/src/mux_h2.c
+++ b/src/mux_h2.c
@@ -277,7 +277,7 @@ static inline struct buffer *h2_get_dbuf(struct h2c *h2c)
 
 	if (likely(LIST_ISEMPTY(>dbuf_wait.list)) &&
 	unlikely((buf = b_alloc_margin(>dbuf, 0)) == NULL)) {
-		h2c->dbuf_wait.target = h2c->conn;
+		h2c->dbuf_wait.target = h2c;
 		h2c->dbuf_wait.wakeup_cb = h2_dbuf_available;
 		HA_SPIN_LOCK(BUF_WQ_LOCK, _wq_lock);
 		LIST_ADDQ(_wq, >dbuf_wait.list);
-- 
2.14.3

Re: RE: haproxy tcp mode source ip

[mingbei...@baifendian.com]

Hi:
Thank you very much. I'm trying.



mingbei...@baifendian.com
徐铭贝
数据仓库助理工程师 平台业务部  
Mobile: +86-15801118167
E-mail:mingbei...@baifendian.com
BAIFENDIAN.COM - Big Data Practitioner
北京市朝阳区北辰西路8号院2号楼北辰世纪中心A座16层

 
From: Tom Maher
Date: 2018-02-26 20:07
To: mingbei...@baifendian.com; Aaron West
CC: Wang Bin; haproxy
Subject: RE: Re: haproxy tcp mode source ip
We had a similar requirement. We developed a patch (on 1.8.3) that allows the 
Proxy Protocol TLV PP2_TYPE_NETNS to be configured as part of a bind with a 
“send_netns ”, e.g.:
frontend cfe
bind 192.168.1.20:3128 send_netns 1
mode tcp
 
See below an example capture of the Proxy Protocol v2 with PP2_TYPE_NETSN set 
using send_netns 1:
 
We decided to re-use PP2_TYPE_NETNS as it served our purpose reasonable well 
noting that  is a string. 
 
Below is the 1.8.3 patch. If there is general interest, happy to create a patch 
according to guidelines in “HOW TO GET YOUR CODE ACCEPTED IN HAPROXY” and 
submit to the maintainers.
 
+++ connection.h2018-01-12 12:35:38.0 +
@@ -388,6 +388,7 @@
int (*xprt_done_cb)(struct connection *conn);  /* callback to notify of 
end of handshake */
void (*destroy_cb)(struct connection *conn);  /* callback to notify of 
imminent death of the connection */
const struct netns_entry *proxy_netns;
+   char *send_netns;  /* copied from listen */
struct {
struct sockaddr_storage from;   /* client address, or address 
to spoof when connecting to the server */
struct sockaddr_storage to; /* address reached by the 
client, or address to connect to */
--- ../../../haproxy-1.8.3/include/types/listener.h   2017-12-30 
17:13:19.0 +
+++ listener.h  2018-01-12 12:27:22.0 +
@@ -206,6 +206,7 @@
__decl_hathreads(HA_SPINLOCK_T lock);
 
const struct netns_entry *netns; /* network namespace of the listener*/
+   char *send_netns;  /* value for PP2_TYPE_NETNS */
 
struct list by_fe;  /* chaining in frontend's list of 
listeners */
struct list by_bind;/* chaining in bind_conf's list of 
listeners */
--- ../../haproxy-1.8.3/src/connection.c  2017-12-30 17:13:19.0 
+
+++ connection.c2018-01-12 12:58:38.0 +
@@ -1083,6 +1083,11 @@
ret += make_tlv([ret], (buf_len - ret), PP2_TYPE_NETNS, 
remote->proxy_netns->name_len, remote->proxy_netns->node.key);
}
#endif
+   if (remote && (remote->send_netns)) {
+   if ((buf_len - ret) < sizeof(struct tlv))
+   return 0;
+   ret += make_tlv([ret], (buf_len - ret), PP2_TYPE_NETNS, 
strlen(remote->send_netns), remote->send_netns);
+   }
 
hdr->len = htons((uint16_t)(ret - PP2_HEADER_LEN));
 
--- ../../haproxy-1.8.3-casquette/src/proto_tcp.c   2017-12-30 
17:13:19.0 +
+++ proto_tcp.c 2018-01-12 12:31:29.0 +
@@ -1906,6 +1906,24 @@
}
#endif
 
+/* parse the "send_netns" bind keyword */
+static int bind_parse_send_netns(char **args, int cur_arg, struct proxy *px, 
struct bind_conf *conf, char **err)
+{
+   struct listener *l;
+   char *netns = NULL;
+
+   if (!*args[cur_arg + 1]) {
+   memprintf(err, "'%s' : missing namespace id", args[cur_arg]);
+   return ERR_ALERT | ERR_FATAL;
+   }
+   netns = args[cur_arg + 1];
+
+   list_for_each_entry(l, >listeners, by_bind) {
+   l->send_netns = strdup(netns);
+   }
+   return 0;
+}
+
#ifdef TCP_USER_TIMEOUT
/* parse the "tcp-ut" server keyword */
static int srv_parse_tcp_ut(char **args, int *cur_arg, struct proxy *px, struct 
server *newsrv, char **err)
@@ -1996,6 +2014,7 @@
#ifdef CONFIG_HAP_NS
{ "namespace", bind_parse_namespace,1 },
#endif
+   { "send_netns",bind_parse_send_netns,   1 }, /* PP2_TYPE_NETNS */
/* the versions with the NULL parse function*/
{ "defer-accept",  NULL,  0 },
{ "interface", NULL,  1 },
--- ../../haproxy-1.8.3/src/session.c 2017-12-30 17:13:19.0 +
+++ session.c   2018-01-12 12:35:42.0 +
@@ -141,6 +141,7 @@
cli_conn->flags |= CO_FL_ADDR_FROM_SET;
cli_conn->target = >obj_type;
cli_conn->proxy_netns = l->netns;
+   cli_conn->send_netns = l->send_netns;
 
conn_ctrl_init(cli_conn);
--- ../../../haproxy-1.8.3/include/types/connection.h 2017-12-30 
17:13:19.0 +
 
Regards,
Tom
 
From: mingbei...@baifendian.com  
Sent: 26 February 2018 11:50
To: Aaron West 
Cc: Wang Bin ; haproxy 
Subject: Re: Re: haproxy tcp mode source ip
 
Hi:
Thank you. Is this method IP only displayed in the log? I want to control 
IP privileges.
 


mingbei...@baifendian.com
徐铭贝
数据仓库助理工程师 平台业务部  
Mobile: +86-15801118167

Re: [Gluster-users] NFS Ganesha HA w/ GlusterFS

[Kaleb S. KEITHLEY]

On 02/25/2018 08:29 PM, TomK wrote:
> Hey Guy's,
> 
> A success story instead of a question.
> 
> With your help, managed to get the HA component working with HAPROXY and
> keepalived to build a fairly resilient NFS v4 VM cluster.  ( Used
> Gluster, NFS Ganesha v2.60, HAPROXY, keepalived w/ selinux enabled )
> 
> If someone needs or it could help your work, please PM me for the
> written up post or I could just post here if the lists allow it.
>

Hi,

I strongly encourage you to write a blog post about it. And if not that
at least write about it and post it to the list(s).

I'm not sure why your post to nfs-ganesha-support was blocked. Maybe
it's waiting for some moderator attention. (But I don't believe that
list is moderated.)

Thanks for sharing.

-- 

Kaleb

RE: Re: haproxy tcp mode source ip

[Tom Maher]

We had a similar requirement. We developed a patch (on 1.8.3) that allows the 
Proxy Protocol TLV PP2_TYPE_NETNS to be configured as part of a bind with a 
“send_netns ”, e.g.:

frontend cfe

bind 192.168.1.20:3128 send_netns 1

mode tcp

See below an example capture of the Proxy Protocol v2 with PP2_TYPE_NETSN set 
using send_netns 1:
[cid:image001.png@01D3AEFA.6BB509C0]

We decided to re-use PP2_TYPE_NETNS as it served our purpose reasonable well 
noting that  is a string.

Below is the 1.8.3 patch. If there is general interest, happy to create a patch 
according to guidelines in “HOW TO GET YOUR CODE ACCEPTED IN HAPROXY” and 
submit to the maintainers.


+++ connection.h2018-01-12 12:35:38.0 +

@@ -388,6 +388,7 @@

int (*xprt_done_cb)(struct connection *conn);  /* callback to notify of 
end of handshake */

void (*destroy_cb)(struct connection *conn);  /* callback to notify of 
imminent death of the connection */

const struct netns_entry *proxy_netns;

+   char *send_netns;  /* copied from listen */

struct {

struct sockaddr_storage from;   /* client address, or address 
to spoof when connecting to the server */

struct sockaddr_storage to; /* address reached by the 
client, or address to connect to */

--- ../../../haproxy-1.8.3/include/types/listener.h   2017-12-30 
17:13:19.0 +

+++ listener.h  2018-01-12 12:27:22.0 +

@@ -206,6 +206,7 @@

__decl_hathreads(HA_SPINLOCK_T lock);



const struct netns_entry *netns; /* network namespace of the listener*/

+   char *send_netns;  /* value for PP2_TYPE_NETNS */



struct list by_fe;  /* chaining in frontend's list of 
listeners */

struct list by_bind;/* chaining in bind_conf's list of 
listeners */

--- ../../haproxy-1.8.3/src/connection.c  2017-12-30 17:13:19.0 
+

+++ connection.c2018-01-12 12:58:38.0 +

@@ -1083,6 +1083,11 @@

ret += make_tlv([ret], (buf_len - ret), PP2_TYPE_NETNS, 
remote->proxy_netns->name_len, remote->proxy_netns->node.key);

}

#endif

+   if (remote && (remote->send_netns)) {

+   if ((buf_len - ret) < sizeof(struct tlv))

+   return 0;

+   ret += make_tlv([ret], (buf_len - ret), PP2_TYPE_NETNS, 
strlen(remote->send_netns), remote->send_netns);

+   }



hdr->len = htons((uint16_t)(ret - PP2_HEADER_LEN));



--- ../../haproxy-1.8.3-casquette/src/proto_tcp.c   2017-12-30 
17:13:19.0 +

+++ proto_tcp.c 2018-01-12 12:31:29.0 +

@@ -1906,6 +1906,24 @@

}

#endif



+/* parse the "send_netns" bind keyword */

+static int bind_parse_send_netns(char **args, int cur_arg, struct proxy *px, 
struct bind_conf *conf, char **err)

+{

+   struct listener *l;

+   char *netns = NULL;

+

+   if (!*args[cur_arg + 1]) {

+   memprintf(err, "'%s' : missing namespace id", args[cur_arg]);

+   return ERR_ALERT | ERR_FATAL;

+   }

+   netns = args[cur_arg + 1];

+

+   list_for_each_entry(l, >listeners, by_bind) {

+   l->send_netns = strdup(netns);

+   }

+   return 0;

+}

+

#ifdef TCP_USER_TIMEOUT

/* parse the "tcp-ut" server keyword */

static int srv_parse_tcp_ut(char **args, int *cur_arg, struct proxy *px, struct 
server *newsrv, char **err)

@@ -1996,6 +2014,7 @@

#ifdef CONFIG_HAP_NS

{ "namespace", bind_parse_namespace,1 },

#endif

+   { "send_netns",bind_parse_send_netns,   1 }, /* PP2_TYPE_NETNS */

/* the versions with the NULL parse function*/

{ "defer-accept",  NULL,  0 },

{ "interface", NULL,  1 },

--- ../../haproxy-1.8.3/src/session.c 2017-12-30 17:13:19.0 +

+++ session.c   2018-01-12 12:35:42.0 +

@@ -141,6 +141,7 @@

cli_conn->flags |= CO_FL_ADDR_FROM_SET;

cli_conn->target = >obj_type;

cli_conn->proxy_netns = l->netns;

+   cli_conn->send_netns = l->send_netns;



conn_ctrl_init(cli_conn);

--- ../../../haproxy-1.8.3/include/types/connection.h 2017-12-30 
17:13:19.0 +

Regards,
Tom

From: mingbei...@baifendian.com 
Sent: 26 February 2018 11:50
To: Aaron West 
Cc: Wang Bin ; haproxy 
Subject: Re: Re: haproxy tcp mode source ip

Hi:
Thank you. Is this method IP only displayed in the log? I want to control 
IP privileges.


mingbei...@baifendian.com
徐铭贝
数据仓库助理工程师 平台业务部
Mobile: +86-15801118167
E-mail:mingbei...@baifendian.com

Re: Re: haproxy tcp mode source ip

[mingbei...@baifendian.com]

Hi:
Thank you. Is this method IP only displayed in the log? I want to control 
IP privileges.



mingbei...@baifendian.com
徐铭贝
数据仓库助理工程师 平台业务部  
Mobile: +86-15801118167
E-mail:mingbei...@baifendian.com
BAIFENDIAN.COM - Big Data Practitioner
北京市朝阳区北辰西路8号院2号楼北辰世纪中心A座16层

 
From: Aaron West
Date: 2018-02-26 18:14
To: mingbei...@baifendian.com
CC: Wang Bin; haproxy
Subject: Re: Re: haproxy tcp mode source ip
Yes, you can use TPROXY instead of Proxy Protocol if you don't mind
the additional routing changes(Need to move to two-arm with real
servers setting the GW to be the HAProxy server).
 
You can see an example in this short Blog here:
https://loadbalancer.org/blog/setting-up-haproxy-with-transparent-mode-on-centos-6-x/
 
Aaron West
 
Loadbalancer.org Ltd.
 
www.loadbalancer.org
 
+1 888 867 9504 / +44 (0)330 380 1064
aa...@loadbalancer.org
 
LEAVE A REVIEW | DEPLOYMENT GUIDES | BLOG

Re: Haproxy for Solaris

[Lukas Tribus]

Responded on discourse:
https://discourse.haproxy.org/t/haproxy-installation-for-an-solaris/2167

[PATCH] BUG/MINOR: ssl: return alpn string with NULL terminated

[Emmanuel Hocdet]

Hi,

According to openssl documentation: "SSL_get0_alpn_selected() returns
a pointer to the selected protocol in data with length len. It is not
NUL-terminated". It consern ssl_sock_get_alpn and smp_fetch_ssl_fc_alpn
functions and impact send-proxy-v2 with alpn. The expected get is not
an array of char but a string like other similar functions.

Can you consider this fix?

++
Manu



0001-BUG-MINOR-ssl-return-alpn-string-with-NULL-terminate.patch
Description: Binary data

Re: Re: haproxy tcp mode source ip

[Aaron West]

Yes, you can use TPROXY instead of Proxy Protocol if you don't mind
the additional routing changes(Need to move to two-arm with real
servers setting the GW to be the HAProxy server).

You can see an example in this short Blog here:
https://loadbalancer.org/blog/setting-up-haproxy-with-transparent-mode-on-centos-6-x/

Aaron West

Loadbalancer.org Ltd.

www.loadbalancer.org

+1 888 867 9504 / +44 (0)330 380 1064
aa...@loadbalancer.org

LEAVE A REVIEW | DEPLOYMENT GUIDES | BLOG

[PATCH] BUG/MEDIUM: buffer: Fix bi/bo_putblk in the wrapping case

[Christopher Faulet]

Hi,

Here are 2 patches to fix bi_putblk and bo_putblk in the wrapping case. 
There are 2 patches because the one about bo_putblk must be backported 
to haproxy 1.5 and newer versions while the one about bi_putblk must 
only be backported to 1.8. But the fix is the same.


Thanks
--
Christopher Faulet
>From 5d4575a2f8dcd1d8b75134c0d99178173e0d056e Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Mon, 26 Feb 2018 10:47:03 +0100
Subject: [PATCH 1/2] BUG/MEDIUM: buffer: Fix the wrapping case in bo_putblk

When the block of data need to be split to support the wrapping, the start of
the second block of data was wrong. We must be sure to skip data copied during
the first memcpy.

This patch must be backported to 1.8, 1.7, 1.6 and 1.5.
---
 include/common/buffer.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/common/buffer.h b/include/common/buffer.h
index c92029836..4adfdc647 100644
--- a/include/common/buffer.h
+++ b/include/common/buffer.h
@@ -468,7 +468,7 @@ static inline int bo_putblk(struct buffer *b, const char *blk, int len)
 	memcpy(b->p, blk, half);
 	b->p = b_ptr(b, half);
 	if (len > half) {
-		memcpy(b->p, blk, len - half);
+		memcpy(b->p, blk + half, len - half);
 		b->p = b_ptr(b, half);
 	}
 	b->o += len;
-- 
2.14.3

>From 18c3368cfd67e0d62bb6a4b29a562549a41aef4e Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Mon, 26 Feb 2018 10:51:28 +0100
Subject: [PATCH 2/2] BUG/MEDIUM: buffer: Fix the wrapping case in bi_putblk

When the block of data need to be split to support the wrapping, the start of
the second block of data was wrong. We must be sure to skup data copied during
the first memcpy.

This patch must be backported to 1.8.
---
 include/common/buffer.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/common/buffer.h b/include/common/buffer.h
index 4adfdc647..7ac98bf0d 100644
--- a/include/common/buffer.h
+++ b/include/common/buffer.h
@@ -577,7 +577,7 @@ static inline int bi_putblk(struct buffer *b, const char *blk, int len)
 
 	memcpy(bi_end(b), blk, half);
 	if (len > half)
-		memcpy(b_ptr(b, b->i + half), blk, len - half);
+		memcpy(b_ptr(b, b->i + half), blk + half, len - half);
 	b->i += len;
 	return len;
 }
-- 
2.14.3

Re: Re: haproxy tcp mode source ip

[Wang Bin]

Yes, haproxy has HTTP proxy mode.
You can obtain original IP address in X-Forwarded-For header (which set by
haproxy) in HTTP proxy mode.

2018-02-26 17:23 GMT+08:00 mingbei...@baifendian.com <
mingbei...@baifendian.com>:

> Hi:
> Thank you. haproxy support HTTP1.1 ?   Can Haproxy and TPROXY be ok ?
>
> --
> mingbei...@baifendian.com
> *徐铭贝*
>
> 数据仓库助理工程师 平台业务部
>
> Mobile: +86-15801118167 <+86%20158%200111%208167>
>
> E-mail:mingbei...@baifendian.com
>
> BAIFENDIAN.COM  - Big Data Practitioner
>
> 北京市朝阳区北辰西路8号院2号楼北辰世纪中心A座16层
>
>
>
> *From:* Wang Bin 
> *Date:* 2018-02-26 17:10
> *To:* mingbei...@baifendian.com
> *CC:* haproxy 
> *Subject:* Re: haproxy tcp mode source ip
> It's not possible to obtain original IP address in TCP proxy mode.
> If your backend supports proxy protocol, you can enable proxy protocol
> to pass original IP to your backend.
>
> 2018-02-26 16:06 GMT+08:00 mingbei...@baifendian.com
> :
> > Hi:
> > Hello, great big brother, haproxy gets the source IP in the TCP mode,
> > not the IP address of the haproxy, Thanks;
> >
> > 
> >
> > 徐铭贝
> >
> > Mobile: +86-15801118167 <+86%20158%200111%208167>
>
>

Re: Re: haproxy tcp mode source ip

[mingbei...@baifendian.com]

Hi:
Thank you. haproxy support HTTP1.1 ?   Can Haproxy and TPROXY be ok ?



mingbei...@baifendian.com
徐铭贝
数据仓库助理工程师 平台业务部  
Mobile: +86-15801118167
E-mail:mingbei...@baifendian.com
BAIFENDIAN.COM - Big Data Practitioner
北京市朝阳区北辰西路8号院2号楼北辰世纪中心A座16层

 
From: Wang Bin
Date: 2018-02-26 17:10
To: mingbei...@baifendian.com
CC: haproxy
Subject: Re: haproxy tcp mode source ip
It's not possible to obtain original IP address in TCP proxy mode.
If your backend supports proxy protocol, you can enable proxy protocol
to pass original IP to your backend.
 
2018-02-26 16:06 GMT+08:00 mingbei...@baifendian.com
:
> Hi:
> Hello, great big brother, haproxy gets the source IP in the TCP mode,
> not the IP address of the haproxy, Thanks;
>
> 
>
> 徐铭贝
>
> Mobile: +86-15801118167

Re: haproxy tcp mode source ip

[Wang Bin]

TCP代理模式没法获得原始的IP，如果你的后端程序支持 proxy protocol，用这个。
怎么用自己查文档吧。

2018-02-26 17:10 GMT+08:00 Wang Bin :
> It's not possible to obtain original IP address in TCP proxy mode.
> If your backend supports proxy protocol, you can enable proxy protocol
> to pass original IP to your backend.
>
> 2018-02-26 16:06 GMT+08:00 mingbei...@baifendian.com
> :
>> Hi:
>> Hello, great big brother, haproxy gets the source IP in the TCP mode,
>> not the IP address of the haproxy, Thanks;
>>
>> 
>>
>> 徐铭贝
>>
>> Mobile: +86-15801118167

Re: haproxy tcp mode source ip

[Wang Bin]

It's not possible to obtain original IP address in TCP proxy mode.
If your backend supports proxy protocol, you can enable proxy protocol
to pass original IP to your backend.

2018-02-26 16:06 GMT+08:00 mingbei...@baifendian.com
:
> Hi:
> Hello, great big brother, haproxy gets the source IP in the TCP mode,
> not the IP address of the haproxy, Thanks;
>
> 
>
> 徐铭贝
>
> Mobile: +86-15801118167

haproxy tcp mode source ip

[mingbei...@baifendian.com]

Hi:
Hello, great big brother, haproxy gets the source IP in the TCP mode, not 
the IP address of the haproxy, Thanks;




徐铭贝
Mobile: +86-15801118167