[PATCH 3/4] MINOR: stats: fix typo in help messages
The word "available" was mistakenly written "avalaible" in help messages and
comments.
This patch should be backported to 1.5 and 1.6
---
src/dumpstats.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/dumpstats.c b/src/dumpstats.c
index 4f0c438..182064a 100644
--- a/src/dumpstats.c
+++ b/src/dumpstats.c
@@ -86,7 +86,7 @@ enum {
STAT_CLI_O_CLR, /* clear tables */
STAT_CLI_O_SET, /* set entries in tables */
STAT_CLI_O_STAT, /* dump stats */
- STAT_CLI_O_PATS, /* list all pattern reference avalaible */
+ STAT_CLI_O_PATS, /* list all pattern reference available */
STAT_CLI_O_PAT, /* list all entries of a pattern */
STAT_CLI_O_MLOOK,/* lookup a map entry */
STAT_CLI_O_POOLS,/* dump memory pools */
@@ -364,12 +364,12 @@ static const char stats_sock_usage_msg[] =
" disable: put a server or frontend in maintenance mode\n"
" enable : re-enable a server or frontend which is in
maintenance mode\n"
" shutdown : kill a session or a frontend (eg:to release
listening ports)\n"
- " show acl [id] : report avalaible acls or dump an acl's contents\n"
+ " show acl [id] : report available acls or dump an acl's contents\n"
" get acl: reports the patterns matching a sample for an ACL\n"
" add acl: add acl entry\n"
" del acl: delete acl entry\n"
" clear acl : clear the content of this acl\n"
- " show map [id] : report avalaible maps or dump a map's contents\n"
+ " show map [id] : report available maps or dump a map's contents\n"
" get map: reports the keys and values matching a sample for a
map\n"
" set map: modify map entry\n"
" add map: add map entry\n"
@@ -1458,7 +1458,7 @@ static int stats_sock_parse_request(struct
stream_interface *si, char *line)
else
appctx->ctx.map.display_flags = PAT_REF_ACL;
- /* no parameter: display all map avalaible */
+ /* no parameter: display all map available */
if (!*args[2]) {
appctx->st2 = STAT_ST_INIT;
appctx->st0 = STAT_CLI_O_PATS;
@@ -6117,8 +6117,8 @@ static int stats_tlskeys_list(struct stream_interface
*si) {
/* Now, we start the browsing of the references lists.
* Note that the following call to LIST_ELEM return bad
pointer. The only
-* avalaible field of this pointer is . It is used with
the function
-* tlskeys_list_get_next() for retruning the first avalaible
entry
+* available field of this pointer is . It is used with
the function
+* tlskeys_list_get_next() for retruning the first available
entry
*/
appctx->ctx.tlskeys.ref = LIST_ELEM(&tlskeys_reference, struct
tls_keys_ref *, list);
appctx->ctx.tlskeys.ref =
tlskeys_list_get_next(appctx->ctx.tlskeys.ref, &tlskeys_reference);
@@ -6175,8 +6175,8 @@ static int stats_pats_list(struct stream_interface *si)
/* Now, we start the browsing of the references lists.
* Note that the following call to LIST_ELEM return bad
pointer. The only
-* avalaible field of this pointer is . It is used with
the function
-* pat_list_get_next() for retruning the first avalaible entry
+* available field of this pointer is . It is used with
the function
+* pat_list_get_next() for retruning the first available entry
*/
appctx->ctx.map.ref = LIST_ELEM(&pattern_reference, struct
pat_ref *, list);
appctx->ctx.map.ref = pat_list_get_next(appctx->ctx.map.ref,
&pattern_reference,
--
2.8.1
[PATCH 2/4] BUG/MEDIUM: stats: show backend may show an empty or incomplete result
This is the same issue as "show servers state", where the result is incorrect
it the data can't fit in one buffer. The similar fix is applied, to restart
the data processing where it stopped as buffers are sent to the client.
This fix should be backported to haproxy 1.6
---
include/types/applet.h | 3 +++
src/dumpstats.c| 25 ++---
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/include/types/applet.h b/include/types/applet.h
index bf801f4..eb15456 100644
--- a/include/types/applet.h
+++ b/include/types/applet.h
@@ -136,6 +136,9 @@ struct appctx {
struct server *sv; /* current server being dumped,
NULL = not started yet. */
} server_state;
struct {
+ struct proxy *px; /* current proxy being dumped,
NULL = not started yet. */
+ } be; /* used by "show backends"
command */
+ struct {
char **var;
} env;
} ctx; /* used by stats I/O handlers
to dump the stats */
diff --git a/src/dumpstats.c b/src/dumpstats.c
index a6d021b..4f0c438 100644
--- a/src/dumpstats.c
+++ b/src/dumpstats.c
@@ -1304,6 +1304,7 @@ static int stats_sock_parse_request(struct
stream_interface *si, char *line)
appctx->ctx.stats.flags = 0;
if (strcmp(args[0], "show") == 0) {
if (strcmp(args[1], "backend") == 0) {
+ appctx->ctx.be.px = NULL;
appctx->st2 = STAT_ST_INIT;
appctx->st0 = STAT_CLI_O_BACKEND;
}
@@ -3117,13 +3118,24 @@ static int dump_servers_state(struct stream_interface
*si, struct chunk *buf)
/* Parses backend list and simply report backend names */
static int stats_dump_backend_to_buffer(struct stream_interface *si)
{
+ struct appctx *appctx = __objt_appctx(si->end);
extern struct proxy *proxy;
struct proxy *curproxy;
chunk_reset(&trash);
- chunk_printf(&trash, "# name\n");
- for (curproxy = proxy; curproxy != NULL; curproxy = curproxy->next) {
+ if (!appctx->ctx.be.px) {
+ chunk_printf(&trash, "# name\n");
+ if (bi_putchk(si_ic(si), &trash) == -1) {
+ si_applet_cant_put(si);
+ return 0;
+ }
+ appctx->ctx.be.px = proxy;
+ }
+
+ for (; appctx->ctx.be.px != NULL; appctx->ctx.be.px = curproxy->next) {
+ curproxy = appctx->ctx.be.px;
+
/* looking for backends only */
if (!(curproxy->cap & PR_CAP_BE))
continue;
@@ -3133,11 +3145,10 @@ static int stats_dump_backend_to_buffer(struct
stream_interface *si)
continue;
chunk_appendf(&trash, "%s\n", curproxy->id);
- }
-
- if (bi_putchk(si_ic(si), &trash) == -1) {
- si_applet_cant_put(si);
- return 0;
+ if (bi_putchk(si_ic(si), &trash) == -1) {
+ si_applet_cant_put(si);
+ return 0;
+ }
}
return 1;
--
2.8.1
[PATCH 1/4] BUG/MEDIUM: stats: show servers state may show an empty or incomplete result
It was reported that the unix socket command "show servers state" returned an
empty response while "show servers state " worked.
In fact, both cases can reproduce the issue. It happens when the response can't
fit in one buffer.
The fix consists in processing the response in several steps, as it is done in
some others commands, by restarting where it was stopped after the buffer is
sent to the client.
This fix should be backported to haproxy 1.6
---
include/types/applet.h | 4 ++-
src/dumpstats.c| 73 ++
2 files changed, 47 insertions(+), 30 deletions(-)
diff --git a/include/types/applet.h b/include/types/applet.h
index 562575f..bf801f4 100644
--- a/include/types/applet.h
+++ b/include/types/applet.h
@@ -131,7 +131,9 @@ struct appctx {
struct dns_resolvers *ptr;
} resolvers;
struct {
- struct proxy *backend;
+ int iid;/* if >= 0, ID of the proxy to
filter on */
+ struct proxy *px; /* current proxy being dumped,
NULL = not started yet. */
+ struct server *sv; /* current server being dumped,
NULL = not started yet. */
} server_state;
struct {
char **var;
diff --git a/src/dumpstats.c b/src/dumpstats.c
index bfd5b5c..a6d021b 100644
--- a/src/dumpstats.c
+++ b/src/dumpstats.c
@@ -303,7 +303,7 @@ static int stats_tlskeys_list(struct stream_interface *si);
#endif
static void cli_release_handler(struct appctx *appctx);
-static void dump_servers_state(struct proxy *backend, struct chunk *buf);
+static int dump_servers_state(struct stream_interface *si, struct chunk *buf);
/*
* cli_io_handler()
@@ -1379,18 +1379,21 @@ static int stats_sock_parse_request(struct
stream_interface *si, char *line)
appctx->st0 = STAT_CLI_O_INFO; //
stats_dump_info_to_buffer
}
else if (strcmp(args[1], "servers") == 0 && strcmp(args[2],
"state") == 0) {
- appctx->ctx.server_state.backend = NULL;
+ appctx->ctx.server_state.iid = 0;
+ appctx->ctx.server_state.px = NULL;
+ appctx->ctx.server_state.sv = NULL;
/* check if a backend name has been provided */
if (*args[3]) {
/* read server state from local file */
- appctx->ctx.server_state.backend =
proxy_be_by_name(args[3]);
+ appctx->ctx.server_state.px =
proxy_be_by_name(args[3]);
- if (appctx->ctx.server_state.backend == NULL) {
+ if (!appctx->ctx.server_state.px) {
appctx->ctx.cli.msg = "Can't find
backend.\n";
appctx->st0 = STAT_CLI_PRINT;
return 1;
}
+ appctx->ctx.server_state.iid =
appctx->ctx.server_state.px->uuid;
}
appctx->st2 = STAT_ST_INIT;
appctx->st0 = STAT_CLI_O_SERVERS_STATE; //
stats_dump_servers_state_to_buffer
@@ -3057,20 +3060,21 @@ static int stats_dump_info_to_buffer(struct
stream_interface *si)
* By default, we only export to the last known server state file format.
* These information can be used at next startup to recover same level of
server state.
*/
-static void dump_servers_state(struct proxy *backend, struct chunk *buf)
+static int dump_servers_state(struct stream_interface *si, struct chunk *buf)
{
+ struct appctx *appctx = __objt_appctx(si->end);
struct server *srv;
char srv_addr[INET6_ADDRSTRLEN + 1];
time_t srv_time_since_last_change;
int bk_f_forced_id, srv_f_forced_id;
- /* we don't want to report any state if the backend is not enabled on
this process */
- if (backend->bind_proc && !(backend->bind_proc & (1UL << (relative_pid
- 1
- return;
- srv = backend->srv;
+ /* we don't want to report any state if the backend is not enabled on
this process */
+ if (appctx->ctx.server_state.px->bind_proc &&
!(appctx->ctx.server_state.px->bind_proc & (1UL << (relative_pid - 1
+ return 1;
- while (srv) {
+ for (; appctx->ctx.server_state.sv != NULL; appctx->ctx.server_state.sv
= srv->next) {
+ srv = appctx->ctx.server_state.sv;
srv_addr[0] = '\0';
srv_time_since_last_change = 0;
bk_f_forced_id = 0;
@@ -3087,7 +3091,7 @@ static void dump_servers_state(struct proxy *backend,
struct chunk *buf)
break;
}
srv_time_since_last_cha
[PATCH 4/4] MINOR: stats: show stat resolvers missing in the help message
The help message provided by the "help" command on the unix socket didn't provide "show stat resolvers" in the list of supported commands. This patch should be backported to 1.6 --- src/dumpstats.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/dumpstats.c b/src/dumpstats.c index 182064a..19e2688 100644 --- a/src/dumpstats.c +++ b/src/dumpstats.c @@ -313,7 +313,7 @@ static int dump_servers_state(struct stream_interface *si, struct chunk *buf); * -> stats_dump_backend_to_buffer() // "show backend" * -> stats_dump_servers_state_to_buffer() // "show servers state []" * -> stats_dump_stat_to_buffer() // "show stat" - *-> stats_dump_resolvers_to_buffer() // "show stat resolver " + *-> stats_dump_resolvers_to_buffer() // "show stat resolvers " *-> stats_dump_csv_header() *-> stats_dump_proxy_to_buffer() * -> stats_dump_fe_stats() @@ -350,6 +350,8 @@ static const char stats_sock_usage_msg[] = " show info : report information about the running process\n" " show pools : report information about the memory pools usage\n" " show stat : report counters for each proxy and server\n" + " show stat resolvers [id]: dumps counters from all resolvers section and\n" + "associated name servers\n" " show errors: report last request and response errors for each proxy\n" " show sess [id] : report the list of current sessions or dump this session\n" " show table [id]: report table usage stats or dump this table's contents\n" -- 2.8.1
Re: [PATCH 1/4] BUG/MEDIUM: stats: show servers state may show an empty or incomplete result
On Fri, May 06, 2016 at 12:18:48PM +0200, Cyril Bonté wrote: > It was reported that the unix socket command "show servers state" returned an > empty response while "show servers state " worked. > In fact, both cases can reproduce the issue. It happens when the response > can't > fit in one buffer. > > The fix consists in processing the response in several steps, as it is done in > some others commands, by restarting where it was stopped after the buffer is > sent to the client. > > This fix should be backported to haproxy 1.6 Nice catch and good job. Just merged into 1.7 and will backport asap. I intend to emit a few releases this week-end as we have many bug fixes pending. Thanks! Willy
Re: [PATCH 1/4] BUG/MEDIUM: stats: show servers state may show an empty or incomplete result
Hi Willy, Am 06.05.2016 um 12:29 schrieb Willy Tarreau: Nice catch and good job. Just merged into 1.7 and will backport asap. I intend to emit a few releases this week-end as we have many bug fixes pending. Great. Just a quick reminder though, the following patch on the ML has yet to be ACKed/committed: "BUG/MEDIUM: dns: fix alignment issue when building DNS queries" Regards, Lukas
Re: [PATCH 1/4] BUG/MEDIUM: stats: show servers state may show an empty or incomplete result
Hi Lukas, On Fri, May 06, 2016 at 01:22:52PM +0200, Lukas Tribus wrote: > Hi Willy, > > > Am 06.05.2016 um 12:29 schrieb Willy Tarreau: > > Nice catch and good job. Just merged into 1.7 and will backport asap. > > I intend to emit a few releases this week-end as we have many bug fixes > > pending. > > Great. > > Just a quick reminder though, the following patch on the ML has yet to be > ACKed/committed: > "BUG/MEDIUM: dns: fix alignment issue when building DNS queries" Indeed, let's say that if I don't get any ACK from Baptiste before the release I'll merge it anyway; Thanks! Willy
Re: "show servers state" shows nothing?
Hi all, Le 04/05/2016 23:01, Cyril Bonté a écrit : I could reproduce the issue, it happens when the whole data can't fit in the trash buffer. Usually, haproxy detects that the buffer is full and sends its content to the client, then restarts from where it stopped. But some commands were not implemented to support this. This is at least the case for : - show servers state - show servers state should also fail with many servers - show backend I didn't check other commands but it may also happen in others (show stat resolvers, I believe). I think I can find some time to work on a patch this week-end. Patches have been applied on the development branch, if you want to give it a try (they will be merged soon to 1.6 by Willy). Any feedback appreciated ;-) show server state : http://www.haproxy.org/git?p=haproxy.git;a=commit;h=76a99784f4ced2529e35469ccaa8e803ca397e86 show backend : http://www.haproxy.org/git?p=haproxy.git;a=commit;h=6ca9e01ab2c35c0e6890c7aa6712b0e13ded3db0 -- Cyril Bonté
HAPROXY Configuration
Hi, I have got the support email id for harpoxy through internet. Currently I have some issue related to configuration. I would request you to please guide me. Scenario : Incoming traffic to HAPROXY is : https:///admin https:///rules https:///mgmt In HAproxy, first I need to offload SSl and after offloading I need to send the request to different backend servers as in. https:///admin - ssl offload - url redirect to http://ip:port /analytics/gar https:///rules - ssl offload - url redirect to http://ip:port /service/wec https:///mgmt - ssl offload - url redirect to http://ip:port /authority/vad If you can guide me to define the config rules it will be really appreciated. Thanks, Irshad
Re: WAF in HAProxy
> Am 06.05.2016 um 00:15 schrieb Thierry FOURNIER > : > > Hi, > > You can look here: > > http://discourse.haproxy.org/t/ironbee-in-haproxy/92 > > Thierry > > Is that project actually alive? The last (and what looks like only) commit this year was to adjust the year for the copyright. That in general is not really the most assuring sign for a healthy open source project.
Re: Trying to stop health check messages from being logged
On 5/4/2016 5:30 PM, Chris White wrote: > I am trying to stop backend health check error messages from being > logged to the system console. > But I am still seeing error messages logged when a backend server goes down > 2016 May 4 23:11:14 devtest0 backend web has no server available! It's your syslog server that's actually logging to the console, according to the rules in your syslog config. It does this based on the severity of the message -- it probably has all "emerg" severity messages going to the console. Most people want to be notified of emergencies VERY quickly, so this is a fairly standard setup found by default in syslog daemons. Haproxy logs at the emerg level when a whole backend goes down. It does not log individual servers going down at that severity, but if you have a backend with only one server, it will *seem* like it's notifying you about the server going down. You can stop it completely by reconfiguring the syslog server to exclude the facility being used by haproxy from console notifications. Exactly how to do this may be different for different syslog servers, and is outside the scope of this mailing list. I ran into a similar situation. It makes complete sense for a console notification to happen when a *PRODUCTION* backend goes down, but I do not want to see that information for dev or staging back ends. Those back ends typically only have one server, and that server typically gets bounced a LOT, so the entire backend goes down quite frequently, making for a very noisy console. So I asked the fine folks here what to do about it, and implemented their suggestion. Now I only get notified on the console if all servers in a production backend are down -- which is indeed an emergency that needs immediate attention. Because production websites have more than one server, this is a rare occurrence. This is what I have by default for logging: global log 127.0.0.1 local0 log 127.0.0.1 local1 notice This logs *all* messages to local0, but excludes "info" and "debug" when logging to local1. My syslog config maps local0 to /var/log/debug-haproxy and local1 to /var/log/haproxy. In the backends where I do not want console notifications, I have this: no log log 127.0.0.1 local0 notice err What this does is first turn off all configured default logging, then set up logging for all severity levels between err and notice to local0, my debug destination. The emerg severity notifications are outside this range, so they are not logged at all for that backend. Thanks, Shawn
Managing `Expect: 100-continue` in HAProxy?
We've got HAProxy sitting in front of a menagerie of web servers, none of which handle `Expect: 100-continue` in any way, shape, or form. When someone hits us with a POST from cURL, there's a kind of irritating 1 second delay while cURL waits for the "HTTP/1.1 100 Continue" response. Rather than try to solve it in every application server, I was wondering if there's any way to force HAProxy to send a "100 Continue" response when it gets a POST with "Expect: 100-continue" (and then delete the Expect from the proxied request, of course). It seems like there's already code for sending a 100 Continue if the `http-buffer-request` option is set, so I guess I'm just asking about the feasibility of making that behavior a stand-alone option without having to put the whole request in RAM. -- James Brown Engineer
Re: HAPROXY Configuration
On 7 May 2016 1:04 am, "irshad hassan" wrote: > > Hi, > > I have got the support email id for harpoxy through internet. Currently I have some issue related to configuration. I would request you to please guide me. > > Scenario : > > Incoming traffic to HAPROXY is : > https:///admin > https:///rules > https:///mgmt > > In HAproxy, first I need to offload SSl and after offloading I need to send the request to different backend servers as in. > > https:///admin - ssl offload - url redirect to http://ip:port /analytics/gar > https:///rules - ssl offload - url redirect to http://ip:port /service/wec > https:///mgmt - ssl offload - url redirect to http://ip:port /authority/vad > > If you can guide me to define the config rules it will be really appreciated. > > Thanks, > > Irshad https://www.haproxy.com/doc/aloha/7.0/haproxy/http_rewriting.html
