Re: resolvers - resolv.conf fallback

[Willy Tarreau]

On Fri, Apr 13, 2018 at 03:48:19PM -0600, Ben Draut wrote:
> How about 'parse-resolv-conf' for the current feature, and we reserve
> 'use-system-resolvers' for the feature that Jonathan described?

Perfect! "parse" is quite explicit at least!

Willy

[PATCH] BUG/MINOR: lua: Socket.send causing 'close' needs 1 arguments.

[sada]

---
 src/hlua.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/src/hlua.c b/src/hlua.c
index 60cf8f94..0585a1e7 100644
--- a/src/hlua.c
+++ b/src/hlua.c
@@ -1629,14 +1629,12 @@ __LJMP static int hlua_socket_gc(lua_State *L)
 /* The close function send shutdown signal and break the
  * links between the stream and the object.
  */
-__LJMP static int hlua_socket_close(lua_State *L)
+__LJMP static int hlua_socket_close_helper(lua_State *L)
 {
struct hlua_socket *socket;
struct appctx *appctx;
struct xref *peer;
 
-   MAY_LJMP(check_args(L, 1, "close"));
-
socket = MAY_LJMP(hlua_checksocket(L, 1));
 
/* Check if we run on the same thread than the xreator thread.
@@ -1659,6 +1657,14 @@ __LJMP static int hlua_socket_close(lua_State *L)
return 0;
 }
 
+/* The close function calls close_helper.
+ */
+__LJMP static int hlua_socket_close(lua_State *L)
+{
+   MAY_LJMP(check_args(L, 1, "close"));
+   return hlua_socket_close_helper(L);
+}
+
 /* This Lua function assumes that the stack contain three parameters.
  *  1 - USERDATA containing a struct socket
  *  2 - INTEGER with values of the macro defined below
@@ -1990,7 +1996,7 @@ static int hlua_socket_write_yield(struct lua_State 
*L,int status, lua_KContext
if (len == -1)
s->req.flags |= CF_WAKE_WRITE;
 
-   MAY_LJMP(hlua_socket_close(L));
+   MAY_LJMP(hlua_socket_close_helper(L));
lua_pop(L, 1);
lua_pushinteger(L, -1);
xref_unlock(&socket->xref, peer);
-- 
2.17.0

[PATCH][MINOR]: config: Warn if resolvers section has no namerservers configured

[Ben Draut]

This implements a simple warning for 'resolvers' sections that have no
nameservers.

Previously discussed here:
https://www.mail-archive.com/haproxy@formilux.org/msg29600.html

Thanks,

Ben
From fc6a36dabec89eef0eba13146cecbf157f0675b9 Mon Sep 17 00:00:00 2001
From: Ben Draut 
Date: Fri, 13 Apr 2018 15:43:04 -0600
Subject: [PATCH] MINOR: config: Warn if resolvers has no nameservers

Today, a `resolvers` section may be configured without any `nameserver`
directives, which is useless. This implements a warning when such
sections are detected.

[List thread][1].

(Also trimmed lines with trailing whitespace in this file.)

[1]: https://www.mail-archive.com/haproxy@formilux.org/msg29600.html
---
 src/cfgparse.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/src/cfgparse.c b/src/cfgparse.c
index 37bbf453..e529fc6b 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -1798,7 +1798,7 @@ int cfg_parse_global(const char *file, int linenum, char **args, int kwm)
 }
 			}
 		}
-		
+
 		ha_alert("parsing [%s:%d] : unknown keyword '%s' in '%s' section\n", file, linenum, args[0], "global");
 		err_code |= ERR_ALERT | ERR_FATAL;
 	}
@@ -4785,7 +4785,7 @@ stats_error_parsing:
 	reqlen += strlen(args[4]);
 else
 	reqlen += strlen("HTTP/1.0");
-		
+
 curproxy->check_req = malloc(reqlen);
 curproxy->check_len = snprintf(curproxy->check_req, reqlen,
 			   "%s %s %s\r\n", args[2], args[3], *args[4]?args[4]:"HTTP/1.0");
@@ -5094,7 +5094,7 @@ stats_error_parsing:
 			int cur_arg;
 
 			/* insert x-forwarded-for field, but not for the IP address listed as an except.
-			 * set default options (ie: bitfield, header name, etc) 
+			 * set default options (ie: bitfield, header name, etc)
 			 */
 
 			curproxy->options |= PR_O_FWDFOR | PR_O_FF_ALWAYS;
@@ -6071,7 +6071,7 @@ stats_error_parsing:
 			goto out;
 		}
 
-		/* we must first clear any optional default setting */	
+		/* we must first clear any optional default setting */
 		curproxy->conn_src.opts &= ~CO_SRC_TPROXY_MASK;
 		free(curproxy->conn_src.iface_name);
 		curproxy->conn_src.iface_name = NULL;
@@ -6442,7 +6442,7 @@ stats_error_parsing:
 			err_code |= ERR_ALERT | ERR_FATAL;
 			goto out;
 		}
-	
+
 		if ((strcmp(args[2], "if") == 0 || strcmp(args[2], "unless") == 0)) {
 			if ((cond = build_acl_cond(file, linenum, &curproxy->acl, curproxy, (const char **)args+2, &errmsg)) == NULL) {
 ha_alert("parsing [%s:%d] : error detected while parsing a '%s' condition : %s.\n",
@@ -7336,6 +7336,7 @@ int check_config_validity()
 	struct bind_conf *bind_conf;
 	char *err;
 	struct cfg_postparser *postparser;
+	struct dns_resolvers *curr_resolvers = NULL;
 
 	bind_conf = NULL;
 	/*
@@ -8976,6 +8977,15 @@ out_uri_auth_compat:
 global.tune.max_http_hdr * sizeof(struct hdr_idx_elem),
 MEM_F_SHARED);
 
+	list_for_each_entry(curr_resolvers, &dns_resolvers, list) {
+		if (LIST_ISEMPTY(&curr_resolvers->nameservers)) {
+			ha_warning("config : resolvers '%s' [%s:%d] has no nameservers configured!\n",
+   curr_resolvers->id, curr_resolvers->conf.file, 
+   curr_resolvers->conf.line);
+			err_code |= ERR_WARN;
+		}
+	}
+
 	list_for_each_entry(postparser, &postparsers, list) {
 		if (postparser->func)
 			cfgerr += postparser->func();
-- 
2.14.1

Re: resolvers - resolv.conf fallback

[Ben Draut]

How about 'parse-resolv-conf' for the current feature, and we reserve
'use-system-resolvers' for the feature that Jonathan described?

On Fri, Apr 13, 2018 at 3:46 PM, Willy Tarreau  wrote:

> Hi Jonathan,
>
> On Fri, Apr 13, 2018 at 09:24:54PM +, Jonathan Matthews wrote:
> > On Fri, 13 Apr 2018 at 15:09, Willy Tarreau  wrote:
> >
> > > On Fri, Apr 13, 2018 at 08:01:13AM -0600, Ben Draut wrote:
> > > > How about this:
> > > >
> > > > * New directive: 'use_system_nameservers'
> > >
> > > OK, just use dashes ('-') instead of underscores as this is what we
> mostly
> > > use on other keywords, except a few historical mistakes.
> >
> >
> > I'm *definitely* not trying to bikeshed here, but from an Ops
> perspective a
> > reasonable implication of  "use_system_nameservers" would be for the
> > resolution process to track the currently configured contents of
> > resolv.conf over time.
> >
> > AIUI this will actually parse once, at proxy startup, which I suggest
> > should be made more obvious in the naming.
>
> That's a very good point. Maybe "same-as-resolv-conf" or something
> similar would make it more obvious ?
>
> > If I'm wrong, or splitting hairs, please ignore!
>
> Better split hair before features get released and we confuse them all
> the time! There are a few names I'm not proud of you know ;-)
>
> Willy
>

Re: resolvers - resolv.conf fallback

[Willy Tarreau]

Hi Jonathan,

On Fri, Apr 13, 2018 at 09:24:54PM +, Jonathan Matthews wrote:
> On Fri, 13 Apr 2018 at 15:09, Willy Tarreau  wrote:
> 
> > On Fri, Apr 13, 2018 at 08:01:13AM -0600, Ben Draut wrote:
> > > How about this:
> > >
> > > * New directive: 'use_system_nameservers'
> >
> > OK, just use dashes ('-') instead of underscores as this is what we mostly
> > use on other keywords, except a few historical mistakes.
> 
> 
> I'm *definitely* not trying to bikeshed here, but from an Ops perspective a
> reasonable implication of  "use_system_nameservers" would be for the
> resolution process to track the currently configured contents of
> resolv.conf over time.
> 
> AIUI this will actually parse once, at proxy startup, which I suggest
> should be made more obvious in the naming.

That's a very good point. Maybe "same-as-resolv-conf" or something
similar would make it more obvious ?

> If I'm wrong, or splitting hairs, please ignore!

Better split hair before features get released and we confuse them all
the time! There are a few names I'm not proud of you know ;-)

Willy

Re: resolvers - resolv.conf fallback

[Jonathan Matthews]

On Fri, 13 Apr 2018 at 15:09, Willy Tarreau  wrote:

> On Fri, Apr 13, 2018 at 08:01:13AM -0600, Ben Draut wrote:
> > How about this:
> >
> > * New directive: 'use_system_nameservers'
>
> OK, just use dashes ('-') instead of underscores as this is what we mostly
> use on other keywords, except a few historical mistakes.


I'm *definitely* not trying to bikeshed here, but from an Ops perspective a
reasonable implication of  "use_system_nameservers" would be for the
resolution process to track the currently configured contents of
resolv.conf over time.

AIUI this will actually parse once, at proxy startup, which I suggest
should be made more obvious in the naming.

If I'm wrong, or splitting hairs, please ignore!

J

> --
Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html

Re: Health Checks not run before attempting to use backend

[Dave Chiluk]

Well after having read your thread that's disappointing.  An alternative
solution to forcing healthchecks before the bind It would be nice to have
an option to initially start all servers in the down state unless
explicitly loaded as up via a "show servers state
/load-server-state-from-file" option.

Additionally, in a "seamless reload" configuration as we are using, would
it be possible for the new haproxy to complete a healthcheck on backends
after it has bound to the socket, but before it has signaled the old
haproxy, or am I missing another gotcha there.

Also we are doing all this using 1.8.7.

Thanks,
Dave



On Fri, Apr 13, 2018 at 12:35 PM Jonathan Matthews 
wrote:

> On Fri, 13 Apr 2018 at 00:01, Dave Chiluk 
> wrote:
>
>> Is there a way to force haproxy to not use a backend until it passes a
>> healthcheck?  I'm also worried about the side affects this might cause as
>> requests start to queue up in the haproxy
>>
>
> I asked about this in 2014 ("Current solutions to the
> soft-restart-healthcheck-spread problem?") and I don't recall seeing a fix
> since then. Very interested in whatever you find out!
>
>
> J
>
>> --
> Jonathan Matthews
> London, UK
> http://www.jpluscplusm.com/contact.html
>

haproxy.org & jooble

[Emma Vang]

Good day,

My name is Emma Vang and I am Jooble representative.

Jooble is a worldwide job search engine that operates in 65 countries. Every
day more than 2,5 million people all over the world visit our website:
https://jooble.org/.

We would like to offer haproxy.org free banner advertisement on our search
result pages. This way you will increase your brand awareness and
recognition.

In return, we only ask you to add our link on your website.

Please let me know, with whom I communicate on this issue?

Thanks in advance!

Yours faithfully, Emma Vang
Partnership Manager 

t: +44 207 193 28 91 |  
LinkedIn 
skype: e...@jooble.jobs
jooble.org   

 One
site. All jobs
The information in this e-mail is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this e-mail
by anyone else is unauthorized. If you have received this communication in
error, please address with the subject heading "Received in error," send to
the original sender, then delete the e-mail and destroy any copies of it. If
you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and
may be unlawful. Opinions, conclusions and other information in this e-mail
and any attachments that do not relate to the official business of the firm
are neither given nor endorsed by it.

Jooble cannot guarantee that e-mail communications are secure or error-free,
as information could be intercepted, corrupted, amended, lost, destroyed,
arrive late or incomplete, or contain viruses. By this email Jooble neither
makes nor accepts legally binding agreements unless otherwise agreed to the
contrary in written.

Jooble is a Trademark and refers to companies of Jooble Group. Each member
firm of Jooble Group is a legally distinct and separate entity and each
describes itself as such. Information about the structure and jurisdiction
of your local Jooble member firm can be obtained from your Jooble
representative.






 

Re: Segfault in haproxy v1.8 with Lua

[Hessam Mirsadeghi]

I see your point. Thanks for your help.

On Fri, Apr 13, 2018 at 4:20 AM, Christopher Faulet 
wrote:

> Le 12/04/2018 à 17:41, Hessam Mirsadeghi a écrit :
>
>> But using an applet on a request will prevent the request from being sent
>> to the backend servers; I still want backend servers to receive the request.
>>
> So, there is nothing much to do apart writing a filter. As I said, this is
> not trivial at all. And unfortunately, to rewrite the entire response, the
> current filter API will not be your friend. But, definitely, this cannot be
> achieved using Lua. HAProxy was not designed to do HTTP messages rewriting.
>
> --
> Christopher Faulet
>

Re: Health Checks not run before attempting to use backend

[Jonathan Matthews]

On Fri, 13 Apr 2018 at 00:01, Dave Chiluk  wrote:

> Is there a way to force haproxy to not use a backend until it passes a
> healthcheck?  I'm also worried about the side affects this might cause as
> requests start to queue up in the haproxy
>

I asked about this in 2014 ("Current solutions to the
soft-restart-healthcheck-spread problem?") and I don't recall seeing a fix
since then. Very interested in whatever you find out!


J

> --
Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html

Re: HAProxy 1.8.X crashing

[Willy Tarreau]

Hi Praveen,

On Fri, Apr 13, 2018 at 02:03:47PM +, UPPALAPATI, PRAVEEN wrote:
> Hi Oliver,
> 
> The crash got fixed with the patch you provided before. 

Thanks for this useful feedback!

> Do you thing the latest patch will be the right solution?

It should, and if it doesn't, it means we have other bugs at other places
that could still strike on rare situations (eg: memory shortage), so that's
why I really want to ensure that we make the code more robust against this
case. The muxes are a very new thing introduced into haproxy, I'm not that
much surprized that we got a few such inconsistencies, but in general since
they affect everything, any such bug there has a very high risk of being
triggered, which is why I'm confident enough for the long term : if you
don't get it anymore, it's really likely that it's fixed.

Thanks,
Willy

Re: HAProxy 1.8.X crashing

[Olivier Houchard]

Hi Praveen,

On Fri, Apr 13, 2018 at 02:03:47PM +, UPPALAPATI, PRAVEEN wrote:
> Hi Oliver,
> 
> The crash got fixed with the patch you provided before. 
> 
> Do you thing the latest patch will be the right solution?
> 
> Thanks,
> Praveen.
> 

It should be fine.
Regards,

Olivier

Re: resolvers - resolv.conf fallback

[Willy Tarreau]

On Fri, Apr 13, 2018 at 08:01:13AM -0600, Ben Draut wrote:
> How about this:
> 
> * New directive: 'use_system_nameservers'

OK, just use dashes ('-') instead of underscores as this is what we mostly
use on other keywords, except a few historical mistakes.

> * Parse /etc/resolv.conf for nameservers when new directive is seen when
> parsing resolvers.

OK.

> * Make check_config_validity issue a warning for each resolvers section
> that has an empty nameservers list.

OK.

> Thoughts?

All of this sounds perfect.

Thanks,
Willy

RE: HAProxy 1.8.X crashing

[UPPALAPATI, PRAVEEN]

Hi Oliver,

The crash got fixed with the patch you provided before. 

Do you thing the latest patch will be the right solution?

Thanks,
Praveen.

-Original Message-
From: Olivier Houchard [mailto:ohouch...@haproxy.com] 
Sent: Friday, April 13, 2018 8:57 AM
To: Willy Tarreau 
Cc: UPPALAPATI, PRAVEEN ; haproxy@formilux.org
Subject: Re: HAProxy 1.8.X crashing

Hi,

On Thu, Apr 12, 2018 at 11:33:43PM +0200, Willy Tarreau wrote:
> That may be the problem. But if a mux fails to initialize, then we can't
> destroy them either ? Is cs_destroy() the problem here maybe ? If so, I
> suspect that this approach would be more robust and would better match
> the validity tests on conn->mux that are performed at many places in the
> connection code :
> 
>   if (cs->conn->mux) {
>   cs->conn->mux->detach(cs);
>   } else {
> conn_stop_tracking(cs->conn);
> conn_xprt_close(cs->conn);
> conn_free(cs->conn);
> }
> cs_free(cs);
> 
> > >   - one above the return SF_ERR_INTERNAL above in connect_server() to
> > > handle the case where the connection already exists but not the mux.
> > 
> > I'm not sure how this can happen, and what we should do if that happens.
> 
> At least in the current situation we pre-create a connection just to start
> to fill some information (source/destination address), without knowing the
> mux yet. It's an initialization process, it may look beautiful or ugly
> depending on the perspective, but in any case we must ensure that the
> code overall remains reliable in this situation. And to me it looks less
> ugly than picking a possibly wrong mux just to have a valid pointer
> avoiding a segfault.
> 
> But if it turns out that stabilizing the destroy path (or error path) is
> not sufficient and that it breaks somewhere else, we can well adopt this
> solution for the short term and see how to address it for the long term;
> we already know that the outgoing connection code is severely limited to
> the point of currently preventing us from using H2 on the backend, and
> that's exactly why we're currently working on it.

Ok, here is a patch that does exactly what you suggest. I'm not entirely
happy with it, but it'll do the job, as a stopgap. I want this crash
fixed :)

Olivier

Re: HAProxy 1.8.X crashing

[Willy Tarreau]

On Fri, Apr 13, 2018 at 03:56:31PM +0200, Olivier Houchard wrote:
> Ok, here is a patch that does exactly what you suggest. I'm not entirely
> happy with it, but it'll do the job, as a stopgap. I want this crash
> fixed :)

Great, now merged, thank you! If you don't mind, I changed the tag to
BUG/MEDIUM since the bug is causing a crash. And if you mind it's too
late :-)

Willy

Re: resolvers - resolv.conf fallback

[Ben Draut]

How about this:

* New directive: 'use_system_nameservers'
* Parse /etc/resolv.conf for nameservers when new directive is seen when
parsing resolvers.
* Make check_config_validity issue a warning for each resolvers section
that has an empty nameservers list.

Thoughts?

On Tue, Apr 10, 2018 at 3:12 PM, Ben Draut  wrote:

> I agree.
>
> On Mon, Apr 9, 2018 at 1:35 AM, Baptiste  wrote:
>
>>
>>
>> On Fri, Apr 6, 2018 at 4:54 PM, Willy Tarreau  wrote:
>>
>>> On Fri, Apr 06, 2018 at 04:50:54PM +0200, Lukas Tribus wrote:
>>> > > Well, sometimes when you're debugging a configuration, it's nice to
>>> be
>>> > > able to disable some elements. Same for those manipulating/building
>>> > > configs by assembling elements and iteratively pass them through
>>> > > "haproxy -c". That's exactly the reason why we relaxed a few checks
>>> in
>>> > > the past, like accepting a frontend with no bind line or accepting a
>>> > > backend with a "cookie" directive with no cookie on server lines. In
>>> > > fact we could simply emit a warning when a resolvers section has no
>>> > > resolver nor resolv.conf enabled, but at least accept to start.
>>> >
>>> > Understood; however in this specific case I would argue one would
>>> > remove the "resolver" directive from the server-line(s), instead of
>>> > dropping the nameservers from the global nameserver declaration.
>>>
>>> No, because in order to do this, you also have to remove all references
>>> on all "server" lines, which is quite a pain, and error-prone when you
>>> want to reactivate them.
>>>
>>> > Maybe a config warning would be a compromise for this case?
>>>
>>> Yes, that's what I mentionned above, I'm all in favor of this given that
>>> we can't objectively find a valid use case for an empty resolvers section
>>> in production.
>>>
>>> Cheers,
>>> Willy
>>>
>>
>>
>> Ok, so just to summarize:
>> - we should enable parsing of resolv.conf with a configuration statement
>> in the resolvers section
>> - only nameserver directives from resolv.conf will be parsed for now
>> - parsing of resolv.conf can be used in conjunction with nameserver
>> directives in the resolvers section
>> - HAProxy should emit a warning message when parsing a configuration
>> which has no resolv.conf neither nameserver directives enabled
>>
>> Is that correct?
>>
>> Baptiste
>>
>
>

Re: HAProxy 1.8.X crashing

[Olivier Houchard]

Hi,

On Thu, Apr 12, 2018 at 11:33:43PM +0200, Willy Tarreau wrote:
> That may be the problem. But if a mux fails to initialize, then we can't
> destroy them either ? Is cs_destroy() the problem here maybe ? If so, I
> suspect that this approach would be more robust and would better match
> the validity tests on conn->mux that are performed at many places in the
> connection code :
> 
>   if (cs->conn->mux) {
>   cs->conn->mux->detach(cs);
>   } else {
> conn_stop_tracking(cs->conn);
> conn_xprt_close(cs->conn);
> conn_free(cs->conn);
> }
> cs_free(cs);
> 
> > >   - one above the return SF_ERR_INTERNAL above in connect_server() to
> > > handle the case where the connection already exists but not the mux.
> > 
> > I'm not sure how this can happen, and what we should do if that happens.
> 
> At least in the current situation we pre-create a connection just to start
> to fill some information (source/destination address), without knowing the
> mux yet. It's an initialization process, it may look beautiful or ugly
> depending on the perspective, but in any case we must ensure that the
> code overall remains reliable in this situation. And to me it looks less
> ugly than picking a possibly wrong mux just to have a valid pointer
> avoiding a segfault.
> 
> But if it turns out that stabilizing the destroy path (or error path) is
> not sufficient and that it breaks somewhere else, we can well adopt this
> solution for the short term and see how to address it for the long term;
> we already know that the outgoing connection code is severely limited to
> the point of currently preventing us from using H2 on the backend, and
> that's exactly why we're currently working on it.

Ok, here is a patch that does exactly what you suggest. I'm not entirely
happy with it, but it'll do the job, as a stopgap. I want this crash
fixed :)

Olivier
>From 84f50217a88b2c8bb5152045e912a0e39f12d204 Mon Sep 17 00:00:00 2001
From: Olivier Houchard 
Date: Fri, 13 Apr 2018 15:50:27 +0200
Subject: [PATCH] BUG/MINOR: connection: Make sure we have a mux before calling
 detach().

In some cases, we call cs_destroy() very early, so early the connection
doesn't yet have a mux, so we can't call mux->detach(). In this case,
just destroy the associated connection.

This should be backported to 1.8.
---
 include/proto/connection.h | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/include/proto/connection.h b/include/proto/connection.h
index bc8d88484..8566736fd 100644
--- a/include/proto/connection.h
+++ b/include/proto/connection.h
@@ -699,7 +699,20 @@ static inline void conn_free(struct connection *conn)
 /* Release a conn_stream, and kill the connection if it was the last one */
 static inline void cs_destroy(struct conn_stream *cs)
 {
-   cs->conn->mux->detach(cs);
+   if (cs->conn->mux)
+   cs->conn->mux->detach(cs);
+   else {
+   /* It's too early to have a mux, let's just destroy
+* the connection
+*/
+   struct connection *conn = cs->conn;
+
+   conn_stop_tracking(conn);
+   conn_full_close(conn);
+   if (conn->destroy_cb)
+   conn->destroy_cb(conn);
+   conn_free(conn);
+   }
cs_free(cs);
 }
 
-- 
2.14.3

MINOR: proxy: Add fe_defbe fetcher

[Marcin Deranek]

Hi,

New fetcher which adds ability to retrieve default backend name for
frontend. Should cleanly apply to both 1.8 & 1.9 branches.
Regards,

Marcin Deranek
>From b2eeddea4859ab247b5315fb470706175797d434 Mon Sep 17 00:00:00 2001
From: Marcin Deranek 
Date: Fri, 13 Apr 2018 14:37:50 +0200
Subject: [PATCH] MINOR: proxy: Add fe_defbe fetcher

Patch adds ability to fetch frontend's default backend name in your
logic, so it can be used later to derive other backend names to make routing
decisions.
---
 doc/configuration.txt |  4 
 src/frontend.c| 17 +
 2 files changed, 21 insertions(+)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index 43c91114..1f44b8e3 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -13927,6 +13927,10 @@ fe_name : string
   backends to check from which frontend it was called, or to stick all users
   coming via a same frontend to the same server.
 
+fe_defbe : string
+  Returns a string containing the frontend's default backend name. It can be
+  used in frontends to check which backend will handle requests by default.
+
 sc_bytes_in_rate([,]) : integer
 sc0_bytes_in_rate([]) : integer
 sc1_bytes_in_rate([]) : integer
diff --git a/src/frontend.c b/src/frontend.c
index 94d90f59..d935037d 100644
--- a/src/frontend.c
+++ b/src/frontend.c
@@ -194,6 +194,22 @@ smp_fetch_fe_name(const struct arg *args, struct sample *smp, const char *kw, vo
 	return 1;
 }
 
+/* set string to the name of the default backend */
+static int
+smp_fetch_fe_defbe(const struct arg *args, struct sample *smp, const char *kw, void *private)
+{
+	if (!smp->sess->fe->defbe.be)
+		return 0;
+	smp->data.u.str.str = (char *)smp->sess->fe->defbe.be->id;
+	if (!smp->data.u.str.str)
+		return 0;
+
+	smp->data.type = SMP_T_STR;
+	smp->flags = SMP_F_CONST;
+	smp->data.u.str.len = strlen(smp->data.u.str.str);
+	return 1;
+}
+
 /* set temp integer to the number of HTTP requests per second reaching the frontend.
  * Accepts exactly 1 argument. Argument is a frontend, other types will cause
  * an undefined behaviour.
@@ -241,6 +257,7 @@ static struct sample_fetch_kw_list smp_kws = {ILH, {
 	{ "fe_conn",  smp_fetch_fe_conn,  ARG1(1,FE), NULL, SMP_T_SINT, SMP_USE_INTRN, },
 	{ "fe_id",smp_fetch_fe_id,0,  NULL, SMP_T_SINT, SMP_USE_FTEND, },
 	{ "fe_name",  smp_fetch_fe_name,  0,  NULL, SMP_T_STR,  SMP_USE_FTEND, },
+	{ "fe_defbe", smp_fetch_fe_defbe, 0,  NULL, SMP_T_STR,  SMP_USE_FTEND, },
 	{ "fe_req_rate",  smp_fetch_fe_req_rate,  ARG1(1,FE), NULL, SMP_T_SINT, SMP_USE_INTRN, },
 	{ "fe_sess_rate", smp_fetch_fe_sess_rate, ARG1(1,FE), NULL, SMP_T_SINT, SMP_USE_INTRN, },
 	{ /* END */ },
-- 
2.16.1

Re: Problem installing 1.8.7 -- systemd changes

[Angelo Hongens]

On 13-04-2018 03:58, Shawn Heisey wrote:
I have a script on my system that I use to handle compiling and 
installing a new haproxy version.  That script has 
"EXTRA=haproxy-systemd-wrapper"on the line that does the install.


It looks like that's no longer part of haproxy, and that the systemd 
service definition (included in contrib) just calls haproxy directly. 
USE_SYSTEMD must be set on the compile command when using the contrib 
systemd script, and the systemd development library must be present.


But I don't see anything in CHANGELOG or README that talks about it at 
all, and definitely nothing saying that the wrapper has been removed, 
and nothing mentioning the new compile requirements.


Was there somewhere else that I should have looked for information about 
how to get 1.8 working with systemd?


Shawn,

I ran into the same thing a while back. I don't know what OS you are 
using, but you might want to check these SPEC files I wrote for 
inspiratoin. I'm no expert packager, but it works for me:


https://github.com/AxisNL/haproxy-rpmbuild

I upload the packages I build here: https://haproxy.hongens.nl



--
--

met vriendelijke groet,

Angelo Höngens

Re: 1.8.7 http-tunnel doesn't seem to work? (but default http-keep-alive does)

[Willy Tarreau]

On Fri, Apr 13, 2018 at 06:50:50AM +, Pi Ba wrote:
> Using poll (startup with -dk) the request works properly.

Thank you Pieter!

Willy

Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Sander Hoentjen]

Hi all,

I built Haproxy (1.8.7) against openssl 1.1.1-pre4, and now after 1 hour
running haproxy stops accepting new SSL connections. When I restart it
works again for almost(?) exactly 1 hour, then stops.
Any idea what might be causing this, or where I should look

# haproxy -vv
HA-Proxy version 1.8.7 2018/04/07
Copyright 2000-2018 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
-fwrapv -fno-strict-overflow -Wno-unused-label
  OPTIONS = USE_LINUX_TPROXY=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1
USE_PCRE=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with network namespace support.
Built with zlib version : 1.2.3
Running on zlib version : 1.2.3
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with PCRE version : 7.8 2008-09-05
Running on PCRE version : 7.8 2008-09-05
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with multi-threading support.
Encrypted password support via crypt(3): yes
Built with transparent proxy support using: IP_TRANSPARENT
IPV6_TRANSPARENT IP_FREEBIND
Built with OpenSSL version : OpenSSL 1.1.1-pre4 (beta) 3 Apr 2018
Running on OpenSSL version : OpenSSL 1.1.1-pre4 (beta) 3 Apr 2018
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available filters :
    [TRACE] trace
    [COMP] compression
    [SPOE] spoe

Regards,
Sander Hoentjen

Re: Segfault in haproxy v1.8 with Lua

[Christopher Faulet]

Le 12/04/2018 à 17:41, Hessam Mirsadeghi a écrit :
But using an applet on a request will prevent the request from being 
sent to the backend servers; I still want backend servers to receive the 
request.
So, there is nothing much to do apart writing a filter. As I said, this 
is not trivial at all. And unfortunately, to rewrite the entire 
response, the current filter API will not be your friend. But, 
definitely, this cannot be achieved using Lua. HAProxy was not designed 
to do HTTP messages rewriting.


--
Christopher Faulet

Re: Problem installing 1.8.7 -- systemd changes

[Aleksandar Lazic]

Hi shawn.

Am 13.04.2018 um 03:58 schrieb Shawn Heisey:
> I have a script on my system that I use to handle compiling and
> installing a new haproxy version.  That script has
> "EXTRA=haproxy-systemd-wrapper"on the line that does the install.
> 
> It looks like that's no longer part of haproxy, and that the systemd
> service definition (included in contrib) just calls haproxy directly.
> USE_SYSTEMD must be set on the compile command when using the contrib
> systemd script, and the systemd development library must be present.
> 
> But I don't see anything in CHANGELOG or README that talks about it at
> all, and definitely nothing saying that the wrapper has been removed,
> and nothing mentioning the new compile requirements.
> 
> Was there somewhere else that I should have looked for information about
> how to get 1.8 working with systemd?

In the 1.8 announcement is systemd mentioned
https://www.haproxy.org/news.html
=> https://www.mail-archive.com/haproxy@formilux.org/msg28004.html

There are some information's about systemd in the changelog, a little
bit spreaded as it's a development tool

http://git.haproxy.org/?p=haproxy-1.8.git&a=search&h=HEAD&st=grep&s=systemd%7C+%3A+&sr=1

###
1048 2017/06/02 : 1.8-dev2
1131 - MAJOR: systemd-wrapper: get rid of the wrapper
###

In this document is the systemd also mentioned

https://cbonte.github.io/haproxy-dconv/1.8/management.html
-W
-Ws

You can take a look into the mailling list archive for some discussion
about systemd and other topics.

https://www.mail-archive.com/search?a=1&l=haproxy%40formilux.org&haswords=systemd&x=23&y=7&from=&subject=&datewithin=1d&date=¬words=&o=newest

We are open for contribution to polish docs and other parts of this
project ;-)

> Thanks,
> Shawn

Best regards
Aleks