Re: arm64 builds?
Hi Ilya, On Tue, Nov 05, 2019 at 07:20:43PM +0500, ??? wrote: > only arm64 are available. > we can try arm using cross build, for example. Then don't bother with this, it's likely then that they will not have all the environment available. Maybe even their hardware does not support arm32 at all. It was just a suggestion to try to optimize the solution but even arm64 is already nice to have. > is it common way to use cross build for building haproxy ? Yes it is. Actually I don't think I've built it natively for a very long time now, as even on my laptop I'm used to stick to the cross- compilers which are distributed on the distcc build farm running on the lab load generators :-) In practice just pass "CC=/path/to/gcc" and let it do its job. It will automatically use LD=$(CC) if you don't override it. You may have to pass PCRE_INC/PCRE_LIB, SSL_INC/SSL_LIB, LUA_INC/LUA_LIB but that's about all. Just for reference here's the command line I'm using when building (and a variant with -O0 which builds in 3.5 seconds). It may look large because I force all debugging options but it's in a script so I don't have to type it :-) PATH=/f/tc/x86_64-gcc47_glibc218-linux-gnu/bin:$PATH make -j 120 TMPDIR=/dev/shm DISTCC_FALLBACK=0 DISTCC_SKIP_LOCAL_RETRY=0 DISTCC_BACKOFF_PERIOD=0 DISTCC_PAUSE_TIME_MSEC=50 DISTCC_HOSTS="--localslots_cpp=120 10.0.0.235/120,lzo" CC=/g/public/linux/master/x86_64-gcc47_glibc218-linux-gnu-gcc TARGET=linux-glibc DEP= USE_PCRE=1 PCREDIR= DEFINE="-DDEBUG_DONT_SHARE_POOLS -DDEBUG_MEMORY_POOLS -DDEBUG_UAF -DDEBUG_EXPR -DDEBUG_STRICT -DDEBUG_DEV" USE_OPENSSL=1 USE_ZLIB=1 USE_LUA=1 LUA_LIB_NAME=lua EXTRA= USE_SLZ=1 SLZ_INC=/g/public/slz/src SLZ_LIB=/g/public/slz USE_ZLIB= USE_DEVICEATLAS=1 DEVICEATLAS_SRC=contrib/deviceatlas USE_51DEGREES=1 51DEGREES_SRC=contrib/51d/src/trie USE_WURFL=1 WURFL_INC=contrib/wurfl WURFL_LIB=contrib/wurfl CPU_CFLAGS="-O2" "$@" When testing with various local openssl branches I do have another variant of this which uses the local, native pre-processor and linkers, and remote compilers. It's a bit ugly since they're not on the same version but in practice it works fine. Cheers, Willy
Re: stats http counter issue
Hi Jean, On Tue, Nov 05, 2019 at 04:33:00PM +0100, Jean Wasilewski wrote: > Hi, > > While using the stats socket with the official HAProxy exporter, I > noticed that some metrics seem erronous. While querying for a specific > frontend, the admin socket reported two differents metrics for the same > frontend. > > I made this small onliner two retrieve values (with here an example on > 2XX calls on our frontend `console-online`): > > ``` > $ while true; do echo "show stat" | socat - /run/haproxy/admin.sock |grep \ > -E '\#|FRONT' |grep -E '\#|console' |cut -d, -f41 |xargs -L2 echo; sleep \ > 1; done > hrsp_2xx 2141807 > hrsp_2xx 136536 > hrsp_2xx 2141819 > hrsp_2xx 2141828 > hrsp_2xx 136536 > hrsp_2xx 2141841 > hrsp_2xx 2141846 > hrsp_2xx 136537 > hrsp_2xx 2141854 > hrsp_2xx 2141856 > hrsp_2xx 2141863 > hrsp_2xx 136537 > ``` > > Is this a bug or a misconfiguration? It sounds like you're working in multi-process mode (nbproc > 1). If so, this is the expected behavior since stats are per process. This was one of the drivers for the porting to threads. If for any reason you really want to stick to nbproc, then I'd recommend you to use one stats socket per process (use the "process" directive on each line) and to query both of them individually. But frankly this is painful as it may return conflicting server states during some transitions because the checks are per-process as well. You can replace "nbproc 2" with "nbthread 2" in your config, watch for warnings in case you'd already have a few explicit "process" entries, or even remove nbproc and nbthread to let haproxy start one thread per available core. Hoping this helps, Willy
Re: Product Info
On Wed, Nov 06, 2019 at 05:32:26AM +1000, Rob Thomas wrote: > "Prior to" means "before". So 2.0.6 is when it was fixed. Yep, and by the way, you should use any newer 2.0.X release which will contain many more important fixes than this one that is unlikely to hit anyone outside of a lab purposely built to trigger it (since "http-reuse always" is clearly documented as "must not use with known non-compliant servers"). If unsure, it's always good to check for known fixes here: http://www.haproxy.org/bugs/bugs-2.0.html Willy
Re: [PATCH] bugfix to make do-resolve to use DNS cache
Hi,
On Tue, Nov 05, Baptiste wrote:
> David Birdsong reported a bug last week about http do-resolve action not
> using the DNS cache.
> The patch in attachment fixes this issue.
> There is no github issue associated to this bug.
> Backport status is up to 2.0.
Quick question: are the printf's there on purpose or leftover debug
outputs ?
-Jarno
@@ -73,6 +73,7 @@ int check_trk_action(struct act_rule *rule, struct proxy *px,
char **err)
int act_resolution_cb(struct dns_requester *requester, struct dns_nameserver
*nameserver)
{
struct stream *stream;
+printf("%s %d\n", __FUNCTION__, __LINE__);
if (requester->resolution == NULL)
return 0;
@@ -89,6 +90,7 @@ int act_resolution_cb(struct dns_requester *requester, struct
dns_nameserver *na
int act_resolution_error_cb(struct dns_requester *requester, int error_code)
{
struct stream *stream;
+printf("%s %d\n", __FUNCTION__, __LINE__);
if (requester->resolution == NULL)
return 0;
--
Jarno Huuskonen
Re: [PATCH] bugfix to make do-resolve to use DNS cache
Hi Baptiste,
thanks for the fix, but before taking it, are you really sure it's
the version you wanted to send ? There are a couple of debugging
printf() left so I could remove them by hand but maybe you intended
to send a different patch, thus I'd rather let you double-check.
thanks,
Willy
On Tue, Nov 05, 2019 at 10:04:30AM +0100, Baptiste wrote:
> diff --git a/src/action.c b/src/action.c
> index 7684202..36eedc8 100644
> --- a/src/action.c
> +++ b/src/action.c
> @@ -73,6 +73,7 @@ int check_trk_action(struct act_rule *rule, struct proxy
> *px, char **err)
> int act_resolution_cb(struct dns_requester *requester, struct dns_nameserver
> *nameserver)
> {
> struct stream *stream;
> +printf("%s %d\n", __FUNCTION__, __LINE__);
>
> if (requester->resolution == NULL)
> return 0;
> @@ -89,6 +90,7 @@ int act_resolution_cb(struct dns_requester *requester,
> struct dns_nameserver *na
> int act_resolution_error_cb(struct dns_requester *requester, int error_code)
> {
> struct stream *stream;
> +printf("%s %d\n", __FUNCTION__, __LINE__);
>
> if (requester->resolution == NULL)
> return 0;
> diff --git a/src/dns.c b/src/dns.c
> index 15d40a1..d5bf449 100644
> --- a/src/dns.c
> +++ b/src/dns.c
> @@ -363,8 +363,9 @@ void dns_trigger_resolution(struct dns_requester *req)
>* valid */
> exp = tick_add(res->last_resolution, resolvers->hold.valid);
> if (resolvers->t && (res->status != RSLV_STATUS_VALID ||
> - !tick_isset(res->last_resolution) || tick_is_expired(exp, now_ms)))
> + !tick_isset(res->last_resolution) || tick_is_expired(exp, now_ms)))
> {
> task_wakeup(resolvers->t, TASK_WOKEN_OTHER);
> + }
> }
>
>
> @@ -2150,8 +2151,13 @@ enum act_return dns_action_do_resolve(struct act_rule
> *rule, struct proxy *px,
> struct dns_resolution *resolution;
> struct sample *smp;
> char *fqdn;
> + struct dns_requester *req;
> + struct dns_resolvers *resolvers;
> + struct dns_resolution *res;
> + int exp;
>
> /* we have a response to our DNS resolution */
> + use_cache:
> if (s->dns_ctx.dns_requester && s->dns_ctx.dns_requester->resolution !=
> NULL) {
> resolution = s->dns_ctx.dns_requester->resolution;
> if (resolution->step == RSLV_STEP_RUNNING) {
> @@ -2211,6 +2217,22 @@ enum act_return dns_action_do_resolve(struct act_rule
> *rule, struct proxy *px,
>
> s->dns_ctx.parent = rule;
> dns_link_resolution(s, OBJ_TYPE_STREAM, 0);
> +
> + /* Check if there is a fresh enough response in the cache of our
> associated resolution */
> + req = s->dns_ctx.dns_requester;
> + if (!req || !req->resolution) {
> + dns_trigger_resolution(s->dns_ctx.dns_requester);
> + return ACT_RET_YIELD;
> + }
> + res = req->resolution;
> + resolvers = res->resolvers;
> +
> + exp = tick_add(res->last_resolution, resolvers->hold.valid);
> + if (resolvers->t && res->status == RSLV_STATUS_VALID &&
> tick_isset(res->last_resolution)
> +&& !tick_is_expired(exp, now_ms)) {
> + goto use_cache;
> + }
> +
> dns_trigger_resolution(s->dns_ctx.dns_requester);
> return ACT_RET_YIELD;
> }
> --
> 2.7.4
>
Re: Peers, logs and debugging.
On Tue, Nov 05, 2019 at 11:30:01AM +0100, Frederic Lecaille wrote: > I have missed the case where the listener of the "peers" section is declared > after "log" lines. In such case ->peers_fe is NULL when entering the "log" > line parser. > > So, this last patch is better. Thanks Fred, now merged :-) Willy
Re: [PATCH] doc: fix date and http_date keywords syntax
merged, thanks Cyril. Willy
[PATCH] doc: fix date and http_date keywords syntax
--- doc/configuration.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index d8fe6b650..0bb7313cd 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -13245,7 +13245,7 @@ hex2i Converts a hex string containing two hex digits per input byte to an integer. If the input value cannot be converted, then zero is returned. -http_date([]) +http_date([]) Converts an integer supposed to contain a date since epoch to a string representing this date in a format suitable for use in HTTP header fields. If an offset value is specified, then it is added to the date before the @@ -14066,7 +14066,7 @@ cpu_ns_tot : integer high cpu_calls count, for example when processing many HTTP chunks, and for this reason it is often preferred to log cpu_ns_avg instead. -date([, ]) : integer +date([],[]) : integer Returns the current date as the epoch (number of seconds since 01/01/1970). If an offset value is specified, then it is added to the current date before -- 2.24.0
Re: Product Info
"Prior to" means "before". So 2.0.6 is when it was fixed. On Tue, 5 Nov 2019 at 18:53, wrote: > Hi Team, > > > > My name is Anurag and I am with Wells Fargo division of Application > Products Centre of Excellence (APCoE). > > My duties include researching and Identifying product vendor patches and > releases for products for a subset of 3rd party vendor products. > > This is part of regular exercise(quarterly) to identify latest patches of > the 3rd party vendor products. > > > > I need your assistance to regarding your product HAProxy, as per the NVD > data and CVE-2019-18277- it says A flaw was found in HAProxy before > 2.0.6. So request you to please confirm which is the latest release > available which is fixing this vulnerability. > > > > > > Regards, > > Anurag > >
Re: [PATCH] bugfix to make do-resolve to use DNS cache
Thanks! On Tue, Nov 5, 2019, 1:04 AM Baptiste wrote: > Hi there, > > David Birdsong reported a bug last week about http do-resolve action not > using the DNS cache. > The patch in attachment fixes this issue. > There is no github issue associated to this bug. > Backport status is up to 2.0. > > Baptiste >
stats http counter issue
Hi, While using the stats socket with the official HAProxy exporter, I noticed that some metrics seem erronous. While querying for a specific frontend, the admin socket reported two differents metrics for the same frontend. I made this small onliner two retrieve values (with here an example on 2XX calls on our frontend `console-online`): ``` $ while true; do echo "show stat" | socat - /run/haproxy/admin.sock |grep \ -E '\#|FRONT' |grep -E '\#|console' |cut -d, -f41 |xargs -L2 echo; sleep \ 1; done hrsp_2xx 2141807 hrsp_2xx 136536 hrsp_2xx 2141819 hrsp_2xx 2141828 hrsp_2xx 136536 hrsp_2xx 2141841 hrsp_2xx 2141846 hrsp_2xx 136537 hrsp_2xx 2141854 hrsp_2xx 2141856 hrsp_2xx 2141863 hrsp_2xx 136537 ``` Is this a bug or a misconfiguration? I am running the latest stable version of HAProxy (2.0.8-1ppa1~xenial). Thank you in advance, Jean Wasilewski signature.asc Description: PGP signature
Re: arm64 builds?
пн, 4 нояб. 2019 г. в 17:49, Willy Tarreau : > Hi Ilya, > > On Mon, Nov 04, 2019 at 12:18:49AM +0500, ??? wrote: > > hello, > > > > should we switch some builds to arm64? > > > > https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support > > Ah that's interesting! I frequently build for arm/arm64 but I agree > it would be nice to have this done more frequently. The two main points > I'm seeing are : > - unsigned chars, which occasionally trigger a warning somewhere > - non-x86 build, which can occasionally trigger a build error if > we accidently rely on an arch-specific function > > In fact I would even suggest that we build for arm instead of arm64 so > that we switch to 32 bits at the same time and have an opportunity to > detect long vs int vs uint64t vs pointer vs size_t issues (typically > places where printf uses "%lu" without a cast for uint64_t). > only arm64 are available. we can try arm using cross build, for example. is it common way to use cross build for building haproxy ? > > Thanks, > Willy >
Re: Peers, logs and debugging.
> On 5 Nov 2019, at 11:30, Frederic Lecaille wrote: > > On 11/5/19 11:06 AM, Frederic Lecaille wrote: >> On 11/4/19 1:52 PM, Willy Tarreau wrote: >>> Hi Yves, >>> >>> On Mon, Nov 04, 2019 at 10:47:23AM +0100, Yves Lafon wrote: Hi, Trying to debug why some replications are stuck between peers, I was wondering if it was possible to have low-level logging of connections or at least TCP states in the peers section to figure out what is happening. There are some information using 'show peers', but it will lack some information (like if there was multiple reconnect attempts in a row). >>> >>> Now that our peers sections are full-featured proxies, I think it should >>> not be hard to implement the "log" directive there at least to enable >>> logging of incoming connections. It's probably as simple as just setting >>> the log_wait field to non-zero. And I agree that peers remain one of the >>> least verbose area of the code, yet are responsible for some long head >>> scratching :-/ >>> >>> Willy >>> >> Hi, >> Here is a patch to support "log" directive in "peers" section. >> I hope this will help. >> Fred. > > I have missed the case where the listener of the "peers" section is declared > after "log" lines. In such case ->peers_fe is NULL when entering the "log" > line parser. > > So, this last patch is better. > > Fred. > <0001-MINOR-peers-Add-log-directive-to-peers-section.patch> Thanks, I’ll try this. -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~Yves
Re: Peers, logs and debugging.
On 11/5/19 11:06 AM, Frederic Lecaille wrote:
On 11/4/19 1:52 PM, Willy Tarreau wrote:
Hi Yves,
On Mon, Nov 04, 2019 at 10:47:23AM +0100, Yves Lafon wrote:
Hi,
Trying to debug why some replications are stuck between peers, I was
wondering if it was possible to have low-level logging of connections
or at
least TCP states in the peers section to figure out what is happening.
There are some information using 'show peers', but it will lack some
information (like if there was multiple reconnect attempts in a row).
Now that our peers sections are full-featured proxies, I think it should
not be hard to implement the "log" directive there at least to enable
logging of incoming connections. It's probably as simple as just setting
the log_wait field to non-zero. And I agree that peers remain one of the
least verbose area of the code, yet are responsible for some long head
scratching :-/
Willy
Hi,
Here is a patch to support "log" directive in "peers" section.
I hope this will help.
Fred.
I have missed the case where the listener of the "peers" section is
declared after "log" lines. In such case ->peers_fe is NULL when
entering the "log" line parser.
So, this last patch is better.
Fred.
>From 408094ce430f762c7c8a56c0e11d011e9a372705 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?=
Date: Tue, 5 Nov 2019 09:57:45 +0100
Subject: [PATCH] MINOR: peers: Add "log" directive to "peers" section.
This patch is easy to review: let's call parse_logsrv() function to parse
"log" directive as this is already for other sections for proxies.
This enable us to log incoming TCP connections for the listeners for "peers"
sections.
Update the documentation for "peers" section.
---
doc/configuration.txt | 6 ++
src/cfgparse.c| 11 +++
2 files changed, 17 insertions(+)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index d8fe6b650..233255c07 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -2138,6 +2138,12 @@ default-server [param*]
enable
This re-enables a disabled peers section which was previously disabled.
+log [len ] [format ] [sample :]
+ [ []]
+ "peers" sections support the same "log" keyword as for the proxies to
+ log information about the "peers" listener. See "log" option for proxies for
+ more details.
+
peer : [param*]
Defines a peer inside a peers section.
If is set to the local peer name (by default hostname, or forced
diff --git a/src/cfgparse.c b/src/cfgparse.c
index eaad6c2cd..2e200e885 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -714,6 +714,17 @@ int cfg_parse_peers(const char *file, int linenum, char **args, int kwm)
}
err_code |= parse_server(file, linenum, args, curpeers->peers_fe, NULL, 0);
}
+ else if (strcmp(args[0], "log") == 0) {
+ if (init_peers_frontend(file, linenum, NULL, curpeers) != 0) {
+ err_code |= ERR_ALERT | ERR_ABORT;
+ goto out;
+ }
+ if (!parse_logsrv(args, >peers_fe->logsrvs, (kwm == KWM_NO), )) {
+ ha_alert("parsing [%s:%d] : %s : %s\n", file, linenum, args[0], errmsg);
+ err_code |= ERR_ALERT | ERR_FATAL;
+ goto out;
+ }
+ }
else if (strcmp(args[0], "peers") == 0) { /* new peers section */
/* Initialize these static variables when entering a new "peers" section*/
bind_line = peer_line = 0;
--
2.20.1
Re: Peers, logs and debugging.
On 11/4/19 1:52 PM, Willy Tarreau wrote:
Hi Yves,
On Mon, Nov 04, 2019 at 10:47:23AM +0100, Yves Lafon wrote:
Hi,
Trying to debug why some replications are stuck between peers, I was
wondering if it was possible to have low-level logging of connections or at
least TCP states in the peers section to figure out what is happening.
There are some information using 'show peers', but it will lack some
information (like if there was multiple reconnect attempts in a row).
Now that our peers sections are full-featured proxies, I think it should
not be hard to implement the "log" directive there at least to enable
logging of incoming connections. It's probably as simple as just setting
the log_wait field to non-zero. And I agree that peers remain one of the
least verbose area of the code, yet are responsible for some long head
scratching :-/
Willy
Hi,
Here is a patch to support "log" directive in "peers" section.
I hope this will help.
Fred.
>From b0c0c7c4981e83f5a748233ddbaba4d0025a4f71 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?=
Date: Tue, 5 Nov 2019 09:57:45 +0100
Subject: [PATCH] MINOR: peers: Add "log" directive to "peers" section.
This patch is easy to review: let's call parse_logsrv() function to parse
"log" directive as this is already for other sections for proxies.
This enable us to log incoming TCP connections for the listeners for "peers"
sections.
Update the documentation for "peers" section.
---
doc/configuration.txt | 6 ++
src/cfgparse.c| 7 +++
2 files changed, 13 insertions(+)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index d8fe6b650..233255c07 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -2138,6 +2138,12 @@ default-server [param*]
enable
This re-enables a disabled peers section which was previously disabled.
+log [len ] [format ] [sample :]
+ [ []]
+ "peers" sections support the same "log" keyword as for the proxies to
+ log information about the "peers" listener. See "log" option for proxies for
+ more details.
+
peer : [param*]
Defines a peer inside a peers section.
If is set to the local peer name (by default hostname, or forced
diff --git a/src/cfgparse.c b/src/cfgparse.c
index eaad6c2cd..5e6bf2c7e 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -714,6 +714,13 @@ int cfg_parse_peers(const char *file, int linenum, char **args, int kwm)
}
err_code |= parse_server(file, linenum, args, curpeers->peers_fe, NULL, 0);
}
+ else if (strcmp(args[0], "log") == 0) {
+ if (!parse_logsrv(args, >peers_fe->logsrvs, (kwm == KWM_NO), )) {
+ ha_alert("parsing [%s:%d] : %s : %s\n", file, linenum, args[0], errmsg);
+ err_code |= ERR_ALERT | ERR_FATAL;
+ goto out;
+ }
+ }
else if (strcmp(args[0], "peers") == 0) { /* new peers section */
/* Initialize these static variables when entering a new "peers" section*/
bind_line = peer_line = 0;
--
2.20.1
[PATCH] bugfix to make do-resolve to use DNS cache
Hi there,
David Birdsong reported a bug last week about http do-resolve action not
using the DNS cache.
The patch in attachment fixes this issue.
There is no github issue associated to this bug.
Backport status is up to 2.0.
Baptiste
From 74e1328ef08de6740c30b5b5989d1413bb904742 Mon Sep 17 00:00:00 2001
From: Baptiste Assmann
Date: Wed, 30 Oct 2019 16:06:53 +0100
Subject: [PATCH] BUG/MINOR: action: do-resolve now use cached response
As reported by David Birdsong on the ML, the HTTP action do-resolve does
not use the DNS cache.
Actually, the action is "registred" to the resolution for said name to
be resolved and wait until an other requester triggers the it. Once the
resolution is finished, then the action is updated with the result.
To trigger this, you must have a server with runtime DNS resolution
enabled and run a do-resolve action with the same fqdn AND they use the
same resolvers section.
This patch fixes this behavior by ensuring the resolution associated to
the action has a valid answer which is not considered as expired. If
those conditions are valid, then we can use it (it's the "cache").
Backport status: 2.0
---
src/action.c | 2 ++
src/dns.c| 24 +++-
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/src/action.c b/src/action.c
index 7684202..36eedc8 100644
--- a/src/action.c
+++ b/src/action.c
@@ -73,6 +73,7 @@ int check_trk_action(struct act_rule *rule, struct proxy *px, char **err)
int act_resolution_cb(struct dns_requester *requester, struct dns_nameserver *nameserver)
{
struct stream *stream;
+printf("%s %d\n", __FUNCTION__, __LINE__);
if (requester->resolution == NULL)
return 0;
@@ -89,6 +90,7 @@ int act_resolution_cb(struct dns_requester *requester, struct dns_nameserver *na
int act_resolution_error_cb(struct dns_requester *requester, int error_code)
{
struct stream *stream;
+printf("%s %d\n", __FUNCTION__, __LINE__);
if (requester->resolution == NULL)
return 0;
diff --git a/src/dns.c b/src/dns.c
index 15d40a1..d5bf449 100644
--- a/src/dns.c
+++ b/src/dns.c
@@ -363,8 +363,9 @@ void dns_trigger_resolution(struct dns_requester *req)
* valid */
exp = tick_add(res->last_resolution, resolvers->hold.valid);
if (resolvers->t && (res->status != RSLV_STATUS_VALID ||
- !tick_isset(res->last_resolution) || tick_is_expired(exp, now_ms)))
+ !tick_isset(res->last_resolution) || tick_is_expired(exp, now_ms))) {
task_wakeup(resolvers->t, TASK_WOKEN_OTHER);
+ }
}
@@ -2150,8 +2151,13 @@ enum act_return dns_action_do_resolve(struct act_rule *rule, struct proxy *px,
struct dns_resolution *resolution;
struct sample *smp;
char *fqdn;
+ struct dns_requester *req;
+ struct dns_resolvers *resolvers;
+ struct dns_resolution *res;
+ int exp;
/* we have a response to our DNS resolution */
+ use_cache:
if (s->dns_ctx.dns_requester && s->dns_ctx.dns_requester->resolution != NULL) {
resolution = s->dns_ctx.dns_requester->resolution;
if (resolution->step == RSLV_STEP_RUNNING) {
@@ -2211,6 +2217,22 @@ enum act_return dns_action_do_resolve(struct act_rule *rule, struct proxy *px,
s->dns_ctx.parent = rule;
dns_link_resolution(s, OBJ_TYPE_STREAM, 0);
+
+ /* Check if there is a fresh enough response in the cache of our associated resolution */
+ req = s->dns_ctx.dns_requester;
+ if (!req || !req->resolution) {
+ dns_trigger_resolution(s->dns_ctx.dns_requester);
+ return ACT_RET_YIELD;
+ }
+ res = req->resolution;
+ resolvers = res->resolvers;
+
+ exp = tick_add(res->last_resolution, resolvers->hold.valid);
+ if (resolvers->t && res->status == RSLV_STATUS_VALID && tick_isset(res->last_resolution)
+ && !tick_is_expired(exp, now_ms)) {
+ goto use_cache;
+ }
+
dns_trigger_resolution(s->dns_ctx.dns_requester);
return ACT_RET_YIELD;
}
--
2.7.4
Product Info
Hi Team, My name is Anurag and I am with Wells Fargo division of Application Products Centre of Excellence (APCoE). My duties include researching and Identifying product vendor patches and releases for products for a subset of 3rd party vendor products. This is part of regular exercise(quarterly) to identify latest patches of the 3rd party vendor products. I need your assistance to regarding your product HAProxy, as per the NVD data and CVE-2019-18277- it says A flaw was found in HAProxy before 2.0.6. So request you to please confirm which is the latest release available which is fixing this vulnerability. [cid:image001.png@01D593E4.5AF415B0] Regards, Anurag
