[PATCH v7 0/3] MEDIUM: Add external check
Add an external check which makes use of an external process to check the status of a server. v7 updates this patchset as per the feedback received for v6 (a very long time ago). Simon Horman (3): MEDIUM: Add port_to_str helper MEDIUM: Break out check establishment into connect_chk() MEDIUM: Add external check doc/configuration.txt | 71 ++ include/common/defaults.h | 1 + include/common/standard.h | 8 + include/types/checks.h| 7 + include/types/global.h| 1 + include/types/proxy.h | 5 +- include/types/server.h| 8 + src/cfgparse.c| 94 +++ src/checks.c | 617 -- src/standard.c| 34 +++ 10 files changed, 770 insertions(+), 76 deletions(-) -- 2.0.0.rc2
[PATCH v7 1/3] MEDIUM: Add port_to_str helper
This helper is similar to addr_to_str but
tries to convert the port rather than the address
of a struct sockaddr_storage.
This is in preparation for supporting
an external agent check.
Signed-off-by: Simon Horman
--
v7
* First post
---
include/common/standard.h | 8
src/standard.c| 34 ++
2 files changed, 42 insertions(+)
diff --git a/include/common/standard.h b/include/common/standard.h
index 8acd277..ecac1e0 100644
--- a/include/common/standard.h
+++ b/include/common/standard.h
@@ -291,6 +291,14 @@ int url2sa(const char *url, int ulen, struct
sockaddr_storage *addr, struct spli
*/
int addr_to_str(struct sockaddr_storage *addr, char *str, int size);
+/* Tries to convert a sockaddr_storage port to text form. Upon success, the
+ * address family is returned so that it's easy for the caller to adapt to the
+ * output format. Zero is returned if the address family is not supported. -1
+ * is returned upon error, with errno set. AF_INET, AF_INET6 and AF_UNIX are
+ * supported.
+ */
+int port_to_str(struct sockaddr_storage *addr, char *str, int size);
+
/* will try to encode the string replacing all characters tagged in
* with the hexadecimal representation of their ASCII-code (2 digits)
* prefixed by , and will store the result between (included)
diff --git a/src/standard.c b/src/standard.c
index 06176d7..5aeaea7 100644
--- a/src/standard.c
+++ b/src/standard.c
@@ -1156,6 +1156,40 @@ int addr_to_str(struct sockaddr_storage *addr, char
*str, int size)
return -1;
}
+/* Tries to convert a sockaddr_storage port to text form. Upon success, the
+ * address family is returned so that it's easy for the caller to adapt to the
+ * output format. Zero is returned if the address family is not supported. -1
+ * is returned upon error, with errno set. AF_INET, AF_INET6 and AF_UNIX are
+ * supported.
+ */
+int port_to_str(struct sockaddr_storage *addr, char *str, int size)
+{
+
+ uint16_t port;
+
+
+ if (size < 5)
+ return 0;
+ *str = '\0';
+
+ switch (addr->ss_family) {
+ case AF_INET:
+ port = ((struct sockaddr_in *)addr)->sin_port;
+ break;
+ case AF_INET6:
+ port = ((struct sockaddr_in6 *)addr)->sin6_port;
+ break;
+ case AF_UNIX:
+ memcpy(str, "unix", 5);
+ return addr->ss_family;
+ default:
+ return 0;
+ }
+
+ snprintf(str, size, "%u", port);
+ return addr->ss_family;
+}
+
/* will try to encode the string replacing all characters tagged in
* with the hexadecimal representation of their ASCII-code (2 digits)
* prefixed by , and will store the result between (included)
--
2.0.0.rc2
[PATCH v7 2/3] MEDIUM: Break out check establishment into connect_chk()
This is in preparation for adding a new type of check that
uses a process rather than a socket.
Signed-off-by: Simon Horman
---
v7
* Use connect_chk() as the name of the new function
* Manual rebase
- Add SN_ERR_UP return value to connect_chk()
to handle the case where the task should be returned
by process_chk() without further processing
Notes by Willy on v6:
I'd rather call it connect_chk() since we already use the verb
"connect" at other places for the same purpose
v4
* Use check->type in establish_conn_chk()
Use check->type instead of s->proxy->options2 & PR_O2_CHK_ANY
as the former is specific to the check being processed whereas
the latter relates only to the primary check of a server.
v2 - v3
* No change
---
src/checks.c | 185 ---
1 file changed, 101 insertions(+), 84 deletions(-)
diff --git a/src/checks.c b/src/checks.c
index e54e46a..6b501de 100644
--- a/src/checks.c
+++ b/src/checks.c
@@ -1351,6 +1351,104 @@ static struct task *server_warmup(struct task *t)
}
/*
+ * establish a server health-check.
+ *
+ * It can return one of :
+ * - SN_ERR_NONE if everything's OK and tcpcheck_main() was not called
+ * - SN_ERR_UP if if everything's OK and tcpcheck_main() was called
+ * - SN_ERR_SRVTO if there are no more servers
+ * - SN_ERR_SRVCL if the connection was refused by the server
+ * - SN_ERR_PRXCOND if the connection has been limited by the proxy (maxconn)
+ * - SN_ERR_RESOURCE if a system resource is lacking (eg: fd limits, ports,
...)
+ * - SN_ERR_INTERNAL for any other purely internal errors
+ * Additionnally, in the case of SN_ERR_RESOURCE, an emergency log will be
emitted.
+ * Note that we try to prevent the network stack from sending the ACK during
the
+ * connect() when a pure TCP check is used (without PROXY protocol).
+ */
+static int connect_chk(struct task *t)
+{
+ struct check *check = t->context;
+ struct server *s = check->server;
+ struct connection *conn = check->conn;
+ struct protocol *proto;
+ int ret;
+
+ /* tcpcheck send/expect initialisation */
+ if (check->type == PR_O2_TCPCHK_CHK)
+ check->current_step = NULL;
+
+ /* prepare the check buffer.
+* This should not be used if check is the secondary agent check
+* of a server as s->proxy->check_req will relate to the
+* configuration of the primary check. Similarly, tcp-check uses
+* its own strings.
+*/
+ if (check->type && check->type != PR_O2_TCPCHK_CHK && !(check->state &
CHK_ST_AGENT)) {
+ bo_putblk(check->bo, s->proxy->check_req, s->proxy->check_len);
+
+ /* we want to check if this host replies to HTTP or SSLv3
requests
+* so we'll send the request, and won't wake the checker up now.
+*/
+ if ((check->type) == PR_O2_SSL3_CHK) {
+ /* SSL requires that we put Unix time in the request */
+ int gmt_time = htonl(date.tv_sec);
+ memcpy(check->bo->data + 11, &gmt_time, 4);
+ }
+ else if ((check->type) == PR_O2_HTTP_CHK) {
+ if (s->proxy->options2 & PR_O2_CHK_SNDST)
+ bo_putblk(check->bo, trash.str,
httpchk_build_status_header(s, trash.str, trash.size));
+ bo_putstr(check->bo, "\r\n");
+ *check->bo->p = '\0'; /* to make gdb output easier to
read */
+ }
+ }
+
+ /* prepare a new connection */
+ conn_init(conn);
+ conn_prepare(conn, s->check_common.proto, s->check_common.xprt);
+ conn_attach(conn, check, &check_conn_cb);
+ conn->target = &s->obj_type;
+
+ /* no client address */
+ clear_addr(&conn->addr.from);
+
+ if (is_addr(&s->check_common.addr)) {
+
+ /* we'll connect to the check addr specified on the server */
+ conn->addr.to = s->check_common.addr;
+ proto = s->check_common.proto;
+ }
+ else {
+ /* we'll connect to the addr on the server */
+ conn->addr.to = s->addr;
+ proto = s->proto;
+ }
+
+ if (check->port) {
+ set_host_port(&conn->addr.to, check->port);
+ }
+
+ if (check->type == PR_O2_TCPCHK_CHK) {
+ struct tcpcheck_rule *r = (struct tcpcheck_rule *)
s->proxy->tcpcheck_rules.n;
+ /* if first step is a 'connect', then tcpcheck_main must run it
*/
+ if (r->action == TCPCHK_ACT_CONNECT) {
+ tcpcheck_main(conn);
+ return SN_ERR_UP;
+ }
+ }
+
+ ret = SN_ERR_INTERNAL;
+ if (proto->connect)
+ ret = proto->connect(conn, check->type, (check->type) ? 0 : 2);
+ conn->flags |= CO_FL_WAKE_DATA;
+ if (s->check.send_proxy)
[PATCH v7 3/3] MEDIUM: Add external check
Add an external check which makes use of an external process to check the status of a server. --- Status: pending v7 * Manual Rebase * Make "option external-check" configuration parameter boolean * Add "external-check command" configuration parameter * Add "external-check path" configuration parameter * Do not export prevailing environment to external check * Add global external-check option that must be set to allow configuration of external-checks * Do not use an anonymous union in struct check Actually, don't use a union at all as adding a non-anonymous one seems more trouble than it is worth * As per coding-style, don't use stdbool * Use addr_to_str and port_to_str instead of getnameinfo which is not portable * Rather than modifying process_chk, which is very sensitive, rename it as process_chk_conn and add a version, process_chk_proc to handle external checks. This involves rather a lot of code duplication but should be safe. Notes by Willy on v6: Problems : - don't use "option xxx " despite the old poor choice introduced with "option httpchk". Options are meant to be booleans. - we need some way to ensure that we can globally disable this feature or better, that it must be explicitly enabled, as it introduces a major security risk (APIs, ...) - probably that we need to have a global prefix path setting for all commands. - anonymous union does not build with gcc-2.95 (still supported) - please don't use stdbool (again), it is not portable and has already broke twice in the past. - getnameinfo is not portable either, better use str2sa() or equivalent (and remove include netdb) - I'm quite worried about the changes with has_conn in process_chk, they're touching a very sensible place, so I think it would be much better to have a distinct process_chk function for external checks (we can even rename process_chk to process_chk_conn) v6 * Correct implementation and documentation of arguments to external-check command so that they are consistent with both each other and ldirectord's external check. The motivation being to allow the same scripts to be used with both haproxy and ldirectord. v5 * Rebase v4 * Remove stray use of s->check in process_chk() The check parameter should be used throughout process_chk() * Layer 7 timeouts of agent checks should be ignored * Ensure that argc is never used uninitialised in prepare_external_check() v3 * Rebase: basically a rewrite of large sections of the code * Merge with the following patches + "external-check: Actually execute command" + "Allow selection of of external-check in configuration file" v2 * If the external command exits normally (WIFEXITED()) is true) then set the check's code to the exit status (WEXITSTATUS()) of the process. * Treat a timeout is a failure case rather than the test having passed * Remove duplicate getnameinfo() call in start_checks() * Remove duplicate assignment of sockaddr argument to getnameinfo(9 which caused the check port and check addr configuration of a server to be ignored. --- doc/configuration.txt | 71 +++ include/common/defaults.h | 1 + include/types/checks.h| 7 + include/types/global.h| 1 + include/types/proxy.h | 5 +- include/types/server.h| 8 + src/cfgparse.c| 94 ++ src/checks.c | 460 +- 8 files changed, 641 insertions(+), 6 deletions(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index 54ccaca..b858a04 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -448,6 +448,7 @@ The following keywords are supported in the "global" section : - chroot - crt-base - daemon + - external-check - gid - group - log @@ -547,6 +548,11 @@ daemon operation. It is equivalent to the command line "-D" argument. It can be disabled by the command line "-db" argument. +external-check + Allows the use of an external agent to perform health checks. + This is disabled by default as a security precaution. + See "option external-check". + gid Changes the process' group ID to . It is recommended that the group ID is dedicated to HAProxy or to a small set of similar daemons. HAProxy must @@ -1323,6 +1329,7 @@ option httplogX X X X option http_proxy(*) X X X X option independent-streams (*) X X X X option ldap-check X - X X +option external-check X - X X option log-health-checks (*) X - X X option log-separate-errors (*) X X X - option logasap (*) X X X
bug: long bind lines causes config not to be loaded
Hi we use here a generator for haproxy configs and this one generates amongst all https frontend using SNI to redirect to endspoints. Basically, we host lot of VMS and the host is NATing/redirecting every served domain to the underlying VM and when we use https. In other words, it terminates SSL on the haproxy front and we are using a certicate per VM. Technically, this was as simple as adding a crt for each vm... This setup worked fine and without a glitch for a time, but it's falling on one host as the generated bind line seems to be too long: bind *:443 ssl crt /etc/ssl/cloud/certs/ovh-r5-2.this-company.net.crt crt /etc/ssl/cloud/certs/prod-appapp1.this-company.net.crt crt /etc/ssl/cloud/certs/appapp1.this-company.net.crt crt /etc/ssl/cloud/certs/prod-somethelse.this-company.net.crt crt /etc/ssl/cloud/certs/someth-else.be.crt crt /etc/ssl/cloud/certs/someth-else.com.crt crt /etc/ssl/cloud/certs/someth-else.eu.crt crt /etc/ssl/cloud/certs/someth-else.fr.crt crt /etc/ssl/cloud/certs/someth-else.mobi.crt crt /etc/ssl/cloud/certs/someth-else.net.crt crt /etc/ssl/cloud/certs/someth-else.org.crt crt /etc/ssl/cloud/certs/somethelse.be.crt crt /etc/ssl/cloud/certs/somethelse.com.crt crt /etc/ssl/cloud/certs/somethelse.eu.crt crt /etc/ssl/cloud/certs/somethelse.fr.crt crt /etc/ssl/cloud/certs/somethelse.mobi.crt crt /etc/ssl/cloud/certs/somethelse.net.crt crt /etc/ssl/cloud/certs/somethelse.org.crt crt /etc/ssl/cloud/certs/e-cov.somethelse.net.crt crt /etc/ssl/cloud/certs/appappapp3.somethelse.net.crt crt /etc/ssl/cloud/certs/www.someth-else.be.crt crt /etc/ssl/cloud/certs/www.someth-else.com.crt crt /etc/ssl/cloud/certs/www.someth-else.eu.crt crt /etc/ssl/cloud/certs/www.someth-else.fr.crt crt /etc/ssl/cloud/certs/www.someth-else.mobi.crt crt /etc/ssl/cloud/certs/www.someth-else.org.crt crt /etc/ssl/cloud/certs/www.somethelse.be.crt crt /etc/ssl/cloud/certs/www.somethelse.com.crt crt /etc/ssl/cloud/certs/www.somethelse.eu.crt crt /etc/ssl/cloud/certs/www.somethelse.fr.crt crt /etc/ssl/cloud/certs/www.somethelse.mobi.crt crt /etc/ssl/cloud/certs/www.somethelse.net.crt crt /etc/ssl/cloud/certs/www.somethelse.org.crt crt /etc/ssl/cloud/certs/www2.somethelse.com.crt crt /etc/ssl/cloud/certs/www2.somethelse.eu.crt crt /etc/ssl/cloud/certs/www2.somethelse.fr.crt crt /etc/ssl/cloud/certs/www2.somethelse.net.crt crt /etc/ssl/cloud/certs/www2.somethelse.org.crt crt /etc/ssl/cloud/certs/prod-appapp4.this-company.net.crt crt /etc/ssl/cloud/certs/appapp4.this-company.net.crt (this line is edited but is as long as the original one) This is how haproxy complains at restart: [ALERT] 163/095929 (3094) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:180]: line too long, truncating at word 65, position 1438: ... [ALERT] 163/095929 (3094) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:180] : 'bind *:443' : 'crt' : missing certificate location [ALERT] 163/095929 (3094) : Error(s) found in configuration file : /etc/haproxy/extra/cloudcontroller.cfg As it first truncates the bind content, it then without surprises fails to load. Is this affordable just to increase the bind argument size limit, maybe to something enoughly large that no one can reach this limit ? -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF Pensez à l’environnement. N’imprimez ce courriel que si vous en avez vraiment besoin. signature.asc Description: OpenPGP digital signature
Re: bug: long bind lines causes config not to be loaded
just forgot to include the version: HA-Proxy version 1.5-dev25-a339395 2014/05/10 On 13/06/2014 10:04, kiorky wrote: > Hi we use here a generator for haproxy configs and this one generates amongst > all https frontend using SNI to redirect to endspoints. > Basically, we host lot of VMS and the host is NATing/redirecting every served > domain to the underlying VM and when we use https. > In other words, it terminates SSL on the haproxy front and we are using a > certicate per VM. > Technically, this was as simple as adding a crt for each vm... > This setup worked fine and without a glitch for a time, but it's falling on > one host as the generated bind line seems to be too long: > > bind *:443 ssl crt /etc/ssl/cloud/certs/ovh-r5-2.this-company.net.crt crt > /etc/ssl/cloud/certs/prod-appapp1.this-company.net.crt crt > /etc/ssl/cloud/certs/appapp1.this-company.net.crt crt > /etc/ssl/cloud/certs/prod-somethelse.this-company.net.crt crt > /etc/ssl/cloud/certs/someth-else.be.crt crt > /etc/ssl/cloud/certs/someth-else.com.crt crt > /etc/ssl/cloud/certs/someth-else.eu.crt crt > /etc/ssl/cloud/certs/someth-else.fr.crt crt > /etc/ssl/cloud/certs/someth-else.mobi.crt crt > /etc/ssl/cloud/certs/someth-else.net.crt crt > /etc/ssl/cloud/certs/someth-else.org.crt crt > /etc/ssl/cloud/certs/somethelse.be.crt crt > /etc/ssl/cloud/certs/somethelse.com.crt crt > /etc/ssl/cloud/certs/somethelse.eu.crt crt > /etc/ssl/cloud/certs/somethelse.fr.crt crt > /etc/ssl/cloud/certs/somethelse.mobi.crt crt > /etc/ssl/cloud/certs/somethelse.net.crt crt > /etc/ssl/cloud/certs/somethelse.org.crt crt > /etc/ssl/cloud/certs/e-cov.somethelse.net.crt crt > /etc/ssl/cloud/certs/appappapp3.somethelse.net.crt crt > /etc/ssl/cloud/certs/www.someth-else.be.crt crt > /etc/ssl/cloud/certs/www.someth-else.com.crt crt > /etc/ssl/cloud/certs/www.someth-else.eu.crt crt > /etc/ssl/cloud/certs/www.someth-else.fr.crt crt > /etc/ssl/cloud/certs/www.someth-else.mobi.crt crt > /etc/ssl/cloud/certs/www.someth-else.org.crt crt > /etc/ssl/cloud/certs/www.somethelse.be.crt crt > /etc/ssl/cloud/certs/www.somethelse.com.crt crt > /etc/ssl/cloud/certs/www.somethelse.eu.crt crt > /etc/ssl/cloud/certs/www.somethelse.fr.crt crt > /etc/ssl/cloud/certs/www.somethelse.mobi.crt crt > /etc/ssl/cloud/certs/www.somethelse.net.crt crt > /etc/ssl/cloud/certs/www.somethelse.org.crt crt > /etc/ssl/cloud/certs/www2.somethelse.com.crt crt > /etc/ssl/cloud/certs/www2.somethelse.eu.crt crt > /etc/ssl/cloud/certs/www2.somethelse.fr.crt crt > /etc/ssl/cloud/certs/www2.somethelse.net.crt crt > /etc/ssl/cloud/certs/www2.somethelse.org.crt crt > /etc/ssl/cloud/certs/prod-appapp4.this-company.net.crt crt > /etc/ssl/cloud/certs/appapp4.this-company.net.crt > (this line is edited but is as long as the original one) > > This is how haproxy complains at restart: > [ALERT] 163/095929 (3094) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:180]: line too long, truncating at > word 65, position 1438: ... > [ALERT] 163/095929 (3094) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:180] : 'bind *:443' : 'crt' : missing > certificate location > [ALERT] 163/095929 (3094) : Error(s) found in configuration file : > /etc/haproxy/extra/cloudcontroller.cfg > > > As it first truncates the bind content, it then without surprises fails to > load. > > Is this affordable just to increase the bind argument size limit, maybe to > something enoughly large that no one can reach this limit ? > > -- > Cordialement, > KiOrKY > GPG Key FingerPrint: 0x1A1194B7681112AF > Pensez à l’environnement. > N’imprimez ce courriel que si vous en avez vraiment besoin. -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF Pensez à l’environnement. N’imprimez ce courriel que si vous en avez vraiment besoin. signature.asc Description: OpenPGP digital signature
RE: long bind lines causes config not to be loaded
Hi, You should use the crt-list option in your bind line, and use a file listing your certificates (one per line) Example : bind *:443 ssl crt-list /etc/haproxy/certificates Regards, Nicolas. > Hi we use here a generator for haproxy configs and this one generates amongst > all https frontend using SNI to redirect to endspoints. > Basically, we host lot of VMS and the host is NATing/redirecting every served > domain to the underlying VM and when we use https. > In other words, it terminates SSL on the haproxy front and we are using a > certicate per VM. > Technically, this was as simple as adding a crt for each vm... > This setup worked fine and without a glitch for a time, but it's falling on > one host as the generated bind line seems to be too long:
Re: long bind lines causes config not to be loaded
Ok, So now i have a working solution: crt /clouds/default crt /clouds HOWEVER i dont suceed in using crt-list which i would prefer as it is more explicit: So i think i'm not using the right syntax to give something on a newline. bind *:443 ssl crt /etc/ssl/cloud/certs/ovh-r5-2.this-company.net.crt crt-list /etc/ssl/cloud/certs/prod-foosql.this-company.net.crt crt-list /etc/ssl/cloud/certs/foosql.this-company.net.crt crt-list /etc/ssl/cloud/certs/prod-somethelse.this-company.net.crt crt-list /etc/ssl/cloud/certs/someth-else.be.crt crt-list /etc/ssl/cloud/certs/someth-else.com.crt crt-list /etc/ssl/cloud/certs/someth-else.eu.crt crt-list /etc/ssl/cloud/certs/someth-else.fr.crt crt-list /etc/ssl/cloud/certs/someth-else.mobi.crt crt-list /etc/ssl/cloud/certs/someth-else.net.crt crt-list /etc/ssl/cloud/certs/someth-else.org.crt crt-list /etc/ssl/cloud/certs/somethelse.be.crt crt-list /etc/ssl/cloud/certs/somethelse.com.crt crt-list /etc/ssl/cloud/certs/somethelse.eu.crt crt-list /etc/ssl/cloud/certs/somethelse.fr.crt crt-list /etc/ssl/cloud/certs/somethelse.mobi.crt crt-list /etc/ssl/cloud/certs/somethelse.net.crt crt-list /etc/ssl/cloud/certs/somethelse.org.crt crt-list /etc/ssl/cloud/certs/e-nnn.somethelse.net.crt crt-list /etc/ssl/cloud/certs/too-mobile.somethelse.net.crt crt-list /etc/ssl/cloud/certs/www.someth-else.be.crt crt-list /etc/ssl/cloud/certs/www.someth-else.com.crt crt-list /etc/ssl/cloud/certs/www.someth-else.eu.crt crt-list /etc/ssl/cloud/certs/www.someth-else.fr.crt crt-list /etc/ssl/cloud/certs/www.someth-else.mobi.crt crt-list /etc/ssl/cloud/certs/www.someth-else.org.crt crt-list /etc/ssl/cloud/certs/www.somethelse.be.crt crt-list /etc/ssl/cloud/certs/www.somethelse.com.crt crt-list /etc/ssl/cloud/certs/www.somethelse.eu.crt crt-list /etc/ssl/cloud/certs/www.somethelse.fr.crt crt-list /etc/ssl/cloud/certs/www.somethelse.mobi.crt crt-list /etc/ssl/cloud/certs/www.somethelse.net.crt crt-list /etc/ssl/cloud/certs/www.somethelse.org.crt crt-list /etc/ssl/cloud/certs/www2.somethelse.com.crt crt-list /etc/ssl/cloud/certs/www2.somethelse.eu.crt crt-list /etc/ssl/cloud/certs/www2.somethelse.fr.crt crt-list /etc/ssl/cloud/certs/www2.somethelse.net.crt crt-list /etc/ssl/cloud/certs/www2.somethelse.org.crt crt-list /etc/ssl/cloud/certs/prod-c.this-company.net.crt crt-list /etc/ssl/cloud/certs/c.this-company.net.crt Gives: [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:182] : unknown keyword 'crt-list' in 'frontend' section [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:183] : unknown keyword 'crt-list' in 'frontend' section [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:184] : unknown keyword 'crt-list' in 'frontend' section [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:185] : unknown keyword 'crt-list' in 'frontend' section [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:186] : unknown keyword 'crt-list' in 'frontend' section [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:187] : unknown keyword 'crt-list' in 'frontend' section [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:188] : unknown keyword 'crt-list' in 'frontend' section [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:189] : unknown keyword 'crt-list' in 'frontend' section [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:190] : unknown keyword 'crt-list' in 'frontend' section [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:191] : unknown keyword 'crt-list' in 'frontend' section [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:192] : unknown keyword 'crt-list' in 'frontend' section [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:193] : unknown keyword 'crt-list' in 'frontend' section [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:194] : unknown keyword 'crt-list' in 'frontend' section [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:195] : unknown keyword 'crt-list' in 'frontend' section [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:196] : unknown keyword 'crt-list' in 'frontend' section [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:197] : unknown keyword 'crt-list' in 'frontend' section [ALERT] 163/102836 (4640) : parsing [/etc/haproxy/extra/cloudcontroller.cfg:198] : unknown keyword 'crt-list' in 'frontend' se
Re: long bind lines causes config not to be loaded
Oh, i think i understood too late your mail :) Trying so to put my certificates paths in a file listing them... On 13/06/2014 10:32, kiorky wrote: > Ok, > So now i have a working solution: > > crt /clouds/default crt /clouds > > HOWEVER i dont suceed in using crt-list which i would prefer as it is more > explicit: > So i think i'm not using the right syntax to give something on a newline. > > > bind *:443 ssl crt /etc/ssl/cloud/certs/ovh-r5-2.this-company.net.crt > crt-list /etc/ssl/cloud/certs/prod-foosql.this-company.net.crt > crt-list /etc/ssl/cloud/certs/foosql.this-company.net.crt > crt-list /etc/ssl/cloud/certs/prod-somethelse.this-company.net.crt > crt-list /etc/ssl/cloud/certs/someth-else.be.crt > crt-list /etc/ssl/cloud/certs/someth-else.com.crt > crt-list /etc/ssl/cloud/certs/someth-else.eu.crt > crt-list /etc/ssl/cloud/certs/someth-else.fr.crt > crt-list /etc/ssl/cloud/certs/someth-else.mobi.crt > crt-list /etc/ssl/cloud/certs/someth-else.net.crt > crt-list /etc/ssl/cloud/certs/someth-else.org.crt > crt-list /etc/ssl/cloud/certs/somethelse.be.crt > crt-list /etc/ssl/cloud/certs/somethelse.com.crt > crt-list /etc/ssl/cloud/certs/somethelse.eu.crt > crt-list /etc/ssl/cloud/certs/somethelse.fr.crt > crt-list /etc/ssl/cloud/certs/somethelse.mobi.crt > crt-list /etc/ssl/cloud/certs/somethelse.net.crt > crt-list /etc/ssl/cloud/certs/somethelse.org.crt > crt-list /etc/ssl/cloud/certs/e-nnn.somethelse.net.crt > crt-list /etc/ssl/cloud/certs/too-mobile.somethelse.net.crt > crt-list /etc/ssl/cloud/certs/www.someth-else.be.crt > crt-list /etc/ssl/cloud/certs/www.someth-else.com.crt > crt-list /etc/ssl/cloud/certs/www.someth-else.eu.crt > crt-list /etc/ssl/cloud/certs/www.someth-else.fr.crt > crt-list /etc/ssl/cloud/certs/www.someth-else.mobi.crt > crt-list /etc/ssl/cloud/certs/www.someth-else.org.crt > crt-list /etc/ssl/cloud/certs/www.somethelse.be.crt > crt-list /etc/ssl/cloud/certs/www.somethelse.com.crt > crt-list /etc/ssl/cloud/certs/www.somethelse.eu.crt > crt-list /etc/ssl/cloud/certs/www.somethelse.fr.crt > crt-list /etc/ssl/cloud/certs/www.somethelse.mobi.crt > crt-list /etc/ssl/cloud/certs/www.somethelse.net.crt > crt-list /etc/ssl/cloud/certs/www.somethelse.org.crt > crt-list /etc/ssl/cloud/certs/www2.somethelse.com.crt > crt-list /etc/ssl/cloud/certs/www2.somethelse.eu.crt > crt-list /etc/ssl/cloud/certs/www2.somethelse.fr.crt > crt-list /etc/ssl/cloud/certs/www2.somethelse.net.crt > crt-list /etc/ssl/cloud/certs/www2.somethelse.org.crt > crt-list /etc/ssl/cloud/certs/prod-c.this-company.net.crt > crt-list /etc/ssl/cloud/certs/c.this-company.net.crt > > > Gives: > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:182] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:183] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:184] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:185] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:186] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:187] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:188] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:189] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:190] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:191] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:192] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:193] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:194] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:195] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/ext
Re: long bind lines causes config not to be loaded
So i confirm that also the crt-list is working as well Many thanks as it solves all of my problems ! On 13/06/2014 10:32, kiorky wrote: > Ok, > So now i have a working solution: > > crt /clouds/default crt /clouds > > HOWEVER i dont suceed in using crt-list which i would prefer as it is more > explicit: > So i think i'm not using the right syntax to give something on a newline. > > > bind *:443 ssl crt /etc/ssl/cloud/certs/ovh-r5-2.this-company.net.crt > crt-list /etc/ssl/cloud/certs/prod-foosql.this-company.net.crt > crt-list /etc/ssl/cloud/certs/foosql.this-company.net.crt > crt-list /etc/ssl/cloud/certs/prod-somethelse.this-company.net.crt > crt-list /etc/ssl/cloud/certs/someth-else.be.crt > crt-list /etc/ssl/cloud/certs/someth-else.com.crt > crt-list /etc/ssl/cloud/certs/someth-else.eu.crt > crt-list /etc/ssl/cloud/certs/someth-else.fr.crt > crt-list /etc/ssl/cloud/certs/someth-else.mobi.crt > crt-list /etc/ssl/cloud/certs/someth-else.net.crt > crt-list /etc/ssl/cloud/certs/someth-else.org.crt > crt-list /etc/ssl/cloud/certs/somethelse.be.crt > crt-list /etc/ssl/cloud/certs/somethelse.com.crt > crt-list /etc/ssl/cloud/certs/somethelse.eu.crt > crt-list /etc/ssl/cloud/certs/somethelse.fr.crt > crt-list /etc/ssl/cloud/certs/somethelse.mobi.crt > crt-list /etc/ssl/cloud/certs/somethelse.net.crt > crt-list /etc/ssl/cloud/certs/somethelse.org.crt > crt-list /etc/ssl/cloud/certs/e-nnn.somethelse.net.crt > crt-list /etc/ssl/cloud/certs/too-mobile.somethelse.net.crt > crt-list /etc/ssl/cloud/certs/www.someth-else.be.crt > crt-list /etc/ssl/cloud/certs/www.someth-else.com.crt > crt-list /etc/ssl/cloud/certs/www.someth-else.eu.crt > crt-list /etc/ssl/cloud/certs/www.someth-else.fr.crt > crt-list /etc/ssl/cloud/certs/www.someth-else.mobi.crt > crt-list /etc/ssl/cloud/certs/www.someth-else.org.crt > crt-list /etc/ssl/cloud/certs/www.somethelse.be.crt > crt-list /etc/ssl/cloud/certs/www.somethelse.com.crt > crt-list /etc/ssl/cloud/certs/www.somethelse.eu.crt > crt-list /etc/ssl/cloud/certs/www.somethelse.fr.crt > crt-list /etc/ssl/cloud/certs/www.somethelse.mobi.crt > crt-list /etc/ssl/cloud/certs/www.somethelse.net.crt > crt-list /etc/ssl/cloud/certs/www.somethelse.org.crt > crt-list /etc/ssl/cloud/certs/www2.somethelse.com.crt > crt-list /etc/ssl/cloud/certs/www2.somethelse.eu.crt > crt-list /etc/ssl/cloud/certs/www2.somethelse.fr.crt > crt-list /etc/ssl/cloud/certs/www2.somethelse.net.crt > crt-list /etc/ssl/cloud/certs/www2.somethelse.org.crt > crt-list /etc/ssl/cloud/certs/prod-c.this-company.net.crt > crt-list /etc/ssl/cloud/certs/c.this-company.net.crt > > > Gives: > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:182] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:183] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:184] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:185] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:186] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:187] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:188] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:189] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:190] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:191] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:192] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:193] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:194] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:195] : unknown keyword 'crt-list' in > 'frontend' section > [ALERT] 163/102836 (4640) : parsing > [/etc/haproxy/extra/cloudcon
Re: long bind lines causes config not to be loaded
On Fri, Jun 13, 2014 at 10:32:34AM +0200, kiorky wrote: > Ok, > So now i have a working solution: > > crt /clouds/default crt /clouds > > HOWEVER i dont suceed in using crt-list which i would prefer as it is more > explicit: > So i think i'm not using the right syntax to give something on a newline. > > > bind *:443 ssl crt /etc/ssl/cloud/certs/ovh-r5-2.this-company.net.crt > crt-list /etc/ssl/cloud/certs/prod-foosql.this-company.net.crt (...) crt-list has a well-defined format, please check the documentation. It specifies an SNI and the associated certificate. Alternatively you can specify a directory in argument to "crt" and everything from that directory will be loaded. Willy
Re: [PATCH v7 0/3] MEDIUM: Add external check
Hi Simon! On Fri, Jun 13, 2014 at 04:18:14PM +0900, Simon Horman wrote: > Add an external check which makes use of an external process to > check the status of a server. > > v7 updates this patchset as per the feedback received for v6 > (a very long time ago). (...) Thanks for this. I'm just wondering if we should try to merge it into 1.5 now of if we should postpone this for 1.6, given that all reported bugs have been fixed and we're polishing the last details. Malcolm, maybe you have an opinion on this ? Regards, Willy
Re: [PATCH v7 0/3] MEDIUM: Add external check
On Fri, Jun 13, 2014 at 10:41:54AM +0200, Willy Tarreau wrote: > Hi Simon! > > On Fri, Jun 13, 2014 at 04:18:14PM +0900, Simon Horman wrote: > > Add an external check which makes use of an external process to > > check the status of a server. > > > > v7 updates this patchset as per the feedback received for v6 > > (a very long time ago). > > (...) > > Thanks for this. I'm just wondering if we should try to merge it into > 1.5 now of if we should postpone this for 1.6, given that all reported > bugs have been fixed and we're polishing the last details. Malcolm, > maybe you have an opinion on this ? I'm happy to defer to Malcolm on that.
Re: long bind lines causes config not to be loaded
Yep, as i said in a replied mail, it's definitely working well ! i had just misread the doc at first and was putting it on the main conf, morning is always hard for me. On 13/06/2014 10:39, Willy Tarreau wrote: > On Fri, Jun 13, 2014 at 10:32:34AM +0200, kiorky wrote: >> Ok, >> So now i have a working solution: >> >> crt /clouds/default crt /clouds >> >> HOWEVER i dont suceed in using crt-list which i would prefer as it is more >> explicit: >> So i think i'm not using the right syntax to give something on a newline. >> >> >> bind *:443 ssl crt /etc/ssl/cloud/certs/ovh-r5-2.this-company.net.crt >> crt-list /etc/ssl/cloud/certs/prod-foosql.this-company.net.crt > (...) > > crt-list has a well-defined format, please check the documentation. It > specifies an SNI and the associated certificate. Alternatively you can > specify a directory in argument to "crt" and everything from that directory > will be loaded. > > Willy > > -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF Pensez à l'environnement. N'imprimez ce courriel que si vous en avez vraiment besoin. signature.asc Description: OpenPGP digital signature
Re: [PATCH v7 0/3] MEDIUM: Add external check
Willy, Much as I'd love to have it right now Its is probably more sensible to go for 1.6, considering the huge effort you have put into getting the 1.5 release out and bug free. I wouldn't want to be the one holding you up. So I'm happy with whatever your decision is. On 13 June 2014 09:41, Willy Tarreau wrote: > Hi Simon! > > On Fri, Jun 13, 2014 at 04:18:14PM +0900, Simon Horman wrote: > > Add an external check which makes use of an external process to > > check the status of a server. > > > > v7 updates this patchset as per the feedback received for v6 > > (a very long time ago). > > (...) > > Thanks for this. I'm just wondering if we should try to merge it into > 1.5 now of if we should postpone this for 1.6, given that all reported > bugs have been fixed and we're polishing the last details. Malcolm, > maybe you have an opinion on this ? > > Regards, > Willy > > -- Regards, Malcolm Turnbull. Loadbalancer.org Ltd. Phone: +44 (0)330 1604540 http://www.loadbalancer.org/
Re: [PATCH v7 0/3] MEDIUM: Add external check
On Fri, Jun 13, 2014 at 10:48:27AM +0100, Malcolm Turnbull wrote: > Willy, > > Much as I'd love to have it right now > Its is probably more sensible to go for 1.6, considering the huge effort > you have put into getting the 1.5 release out and bug free. > I wouldn't want to be the one holding you up. > > So I'm happy with whatever your decision is. OK. I'm thinking one solution could be to merge the code changes needed to enable the feature in order to keep the patch small and limit the review process (patches 1&2 maybe), then later merge the remains in 1.6, let people discuss it, and finally maybe backport it into 1.5-stable if there is demand. Otherwise the patch would remain small and easy to manage for you. That's just an idea, of course. Willy
RE: [chkfail] what went wrong?
Hi, In syslog I see all kinds of things, for example when a server has gone down for maintenance or when I send a SIGHUP to the haproxy process. So why is a failure not being logged? It would really help to at least know when the chkfail has occurred so we can try to relate the issue with messages from the webserver logs or our monitoring-system. Michel -Oorspronkelijk bericht- Van: Michel Hoogervorst Verzonden: woensdag 11 juni 2014 14:21 Aan: 'haproxy@formilux.org' Onderwerp: RE: [chkfail] what went wrong? Hi, I have done some more searching, but cannot lay my finger on what the chkfail's are about. Since the are counted I'd say they must mean "something". I'd really like to know what the chkfail's are about. Is there some special loglevel I could setup to gain more information on these failures? Michel -Oorspronkelijk bericht- Van: Michel Hoogervorst Verzonden: dinsdag 3 juni 2014 12:02 Aan: 'Baptiste' CC: haproxy@formilux.org Onderwerp: RE: [chkfail] what went wrong? Hi, Thanks for your reply. This is how our config looks like (I stripped some non-relevant comments and names): global log 127.0.0.1 local2 chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 2 userhaproxy group haproxy daemon tune.maxrewrite 2048 stats socket /var/lib/haproxy/stats defaults modehttp log global option httplog option dontlognull option dontlog-normal option forwardfor except 127.0.0.0/8 option redispatch retries 3 timeout http-request10s timeout queue 1m timeout connect 10s timeout client 30m timeout server 30m timeout http-keep-alive 10s timeout check 10s maxconn 2 listen webcluster_prod 127.0.0.1:8081 mode http balance hdr(X-Forwarded-For) option contstats option httpchk HEAD /check.txt HTTP/1.0 option httpclose server xxx 10.20.30.1:80 check server yyy 10.20.30.2:80 check When a server goes down I do get a message in the log, so loggins seems to work fine. I just would like to know what the chkfail is about since I only see it in the stats and nowhere else. Kind regards, Michel Hoogervorst -Oorspronkelijk bericht- Van: Baptiste [mailto:bed...@gmail.com] Verzonden: dinsdag 3 juni 2014 11:41 Aan: Michel Hoogervorst CC: haproxy@formilux.org Onderwerp: Re: [chkfail] what went wrong? On Tue, Jun 3, 2014 at 11:28 AM, Michel Hoogervorst wrote: > Hi, > > > > I have checked the documentation but cannot find much information on > chkfail’s in there. > > > > Is there any way to check what went wrong when a “chkfail” has occurred? > > We use a monitoring-plugin that has thresholds set on chkfail’s which > shows me that some machines have multiple chkfail’s every day. > However, no problem is logged both on the HAProxy side and on the > webserver side, and “show errors” on the stats-socket shows 0 errors. > > I’d like to know what happened, and if there has been any impact from > this failure. Is a chkfail always because the server didn’t respond > within 10 seconds or can it be something else? > > Met vriendelijke groet, kind regards, > > Michel Hoogervorst Hi Michel, Maybe you could start by sharing your configuration, then it will be easier to help you. HAProxy setup log severity to notice when a server fails move to status DOWN due to wrong health check response. If you don't retrieve this info in your log it's either because your HAProxy or your syslog server is not well configured (or both of them in the mean time). Baptiste
Re: Some thoughts about redispatch
Hi Dmitry, On Wed, May 28, 2014 at 11:13:24AM +0200, Willy Tarreau wrote: > On Wed, May 28, 2014 at 01:11:47PM +0400, Dmitry Sivachenko wrote: > > On 28 ?? 2014 ??., at 13:06, Willy Tarreau wrote: > > > > > > > > OK but then you make an interesting point with your very low timeout > > > connect. > > > What about using the min of timeout connect and 1s then ? Thus you can > > > simply > > > use your lower timeout connect as this new timeout. Would that be OK for > > > you ? > > > > > > > > > Sounds reasonable (provided we are talking only about redispatch to the same > > server, not to the other one). > > of course :-) > I'll try to sketch something like this then. Done! I've just pushed this. In the end I preferred not to apply this principle to leastconn since there are some situations where leastconn farms can be highly unbalanced (after a server restart) so killing the delay could result in hammering the new fresh server harder. So this is what happens now : - if we're on a round-robin farm with more than 1 active server and the connection is not persistent, then we redispatch upon the first retry since we don't care at all about the server that we randomly picked. - when redispatching, we kill the delay if the farm is in RR with more than one active server. - the delay is always bound by the connect timeout so that sub-second timeouts will lead to shorter retries even for other cases. I just realized during my tests that this way you can have a retries value set to the number of servers and scan your whole farm looking for a server. Yeah this is ugly :-) Regards, Willy
Re: [PATCH v7 2/3] MEDIUM: Break out check establishment into connect_chk()
On Fri, Jun 13, 2014 at 04:18:16PM +0900, Simon Horman wrote: > This is in preparation for adding a new type of check that > uses a process rather than a socket. OK I applied this one, thanks Simon! Willy
Re: [PATCH v7 1/3] MEDIUM: Add port_to_str helper
On Fri, Jun 13, 2014 at 04:18:15PM +0900, Simon Horman wrote:
> This helper is similar to addr_to_str but
> tries to convert the port rather than the address
> of a struct sockaddr_storage.
>
> This is in preparation for supporting
> an external agent check.
I may be wrong, but I'm seeing an endianness issue here, am I wrong ?
The sockaddr_storage stores in network order, so you cannot simply take
the port and print it using "%u" without first applying ntohs().
> +/* Tries to convert a sockaddr_storage port to text form. Upon success, the
> + * address family is returned so that it's easy for the caller to adapt to
> the
> + * output format. Zero is returned if the address family is not supported. -1
> + * is returned upon error, with errno set. AF_INET, AF_INET6 and AF_UNIX are
> + * supported.
> + */
> +int port_to_str(struct sockaddr_storage *addr, char *str, int size)
> +{
> +
> + uint16_t port;
> +
> +
> + if (size < 5)
> + return 0;
> + *str = '\0';
> +
> + switch (addr->ss_family) {
> + case AF_INET:
> + port = ((struct sockaddr_in *)addr)->sin_port;
> + break;
> + case AF_INET6:
> + port = ((struct sockaddr_in6 *)addr)->sin6_port;
> + break;
> + case AF_UNIX:
> + memcpy(str, "unix", 5);
> + return addr->ss_family;
> + default:
> + return 0;
> + }
> +
> + snprintf(str, size, "%u", port);
> + return addr->ss_family;
> +}
Willy
Re: [chkfail] what went wrong?
Hi Michel, On 13/06/2014 17:05, Michel Hoogervorst wrote: Hi, In syslog I see all kinds of things, for example when a server has gone down for maintenance or when I send a SIGHUP to the haproxy process. So why is a failure not being logged? It would really help to at least know when the chkfail has occurred so we can try to relate the issue with messages from the webserver logs or our monitoring-system. What you want is "option log-health-checks" http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20log-health-checks -- Cyril Bonté
RE: [chkfail] what went wrong?
Hi Cyril, Thank you. I haven't found that one before. Will try. :-) Michel -Oorspronkelijk bericht- Van: Cyril Bonté [mailto:cyril.bo...@free.fr] Verzonden: vrijdag 13 juni 2014 18:56 Aan: Michel Hoogervorst CC: 'haproxy@formilux.org' Onderwerp: Re: [chkfail] what went wrong? Hi Michel, On 13/06/2014 17:05, Michel Hoogervorst wrote: > Hi, > > In syslog I see all kinds of things, for example when a server has gone down > for maintenance or when I send a SIGHUP to the haproxy process. So why is a > failure not being logged? > It would really help to at least know when the chkfail has occurred so we can > try to relate the issue with messages from the webserver logs or our > monitoring-system. What you want is "option log-health-checks" http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20log-health-checks -- Cyril Bonté
Re: bug: long bind lines causes config not to be loaded
On Fri, Jun 13, 2014 at 1:08 AM, kiorky wrote: > just forgot to include the version: HA-Proxy version 1.5-dev25-a339395 > 2014/05/10 > > On 13/06/2014 10:04, kiorky wrote: > > Hi we use here a generator for haproxy configs and this one generates > amongst all https frontend using SNI to redirect to endspoints. > Basically, we host lot of VMS and the host is NATing/redirecting every > served domain to the underlying VM and when we use https. > In other words, it terminates SSL on the haproxy front and we are using a > certicate per VM. > Technically, this was as simple as adding a crt for each vm... > This setup worked fine and without a glitch for a time, but it's falling > on one host as the generated bind line seems to be too long: > > bind *:443 ssl crt /etc/ssl/cloud/certs/ovh-r5-2.this-company.net.crt crt > /etc/ssl/cloud/certs/prod-appapp1.this-company.net.crt crt > /etc/ssl/cloud/certs/appapp1.this-company.net.crt crt > /etc/ssl/cloud/certs/prod-somethelse.this-company.net.crt crt > /etc/ssl/cloud/certs/someth-else.be.crt crt > /etc/ssl/cloud/certs/someth-else.com.crt crt > /etc/ssl/cloud/certs/someth-else.eu.crt crt > /etc/ssl/cloud/certs/someth-else.fr.crt crt > /etc/ssl/cloud/certs/someth-else.mobi.crt crt > /etc/ssl/cloud/certs/someth-else.net.crt crt > /etc/ssl/cloud/certs/someth-else.org.crt crt > /etc/ssl/cloud/certs/somethelse.be.crt crt > /etc/ssl/cloud/certs/somethelse.com.crt crt > /etc/ssl/cloud/certs/somethelse.eu.crt crt > /etc/ssl/cloud/certs/somethelse.fr.crt crt > /etc/ssl/cloud/certs/somethelse.mobi.crt crt > /etc/ssl/cloud/certs/somethelse.net.crt crt > /etc/ssl/cloud/certs/somethelse.org.crt crt > /etc/ssl/cloud/certs/e-cov.somethelse.net.crt crt > /etc/ssl/cloud/certs/appappapp3.somethelse.net.crt crt > /etc/ssl/cloud/certs/www.someth-else.be.crt crt > /etc/ssl/cloud/certs/www.someth-else.com.crt crt > /etc/ssl/cloud/certs/www.someth-else.eu.crt crt > /etc/ssl/cloud/certs/www.someth-else.fr.crt crt > /etc/ssl/cloud/certs/www.someth-else.mobi.crt crt > /etc/ssl/cloud/certs/www.someth-else.org.crt crt > /etc/ssl/cloud/certs/www.somethelse.be.crt crt > /etc/ssl/cloud/certs/www.somethelse.com.crt crt > /etc/ssl/cloud/certs/www.somethelse.eu.crt crt > /etc/ssl/cloud/certs/www.somethelse.fr.crt crt > /etc/ssl/cloud/certs/www.somethelse.mobi.crt crt > /etc/ssl/cloud/certs/www.somethelse.net.crt crt > /etc/ssl/cloud/certs/www.somethelse.org.crt crt > /etc/ssl/cloud/certs/www2.somethelse.com.crt crt > /etc/ssl/cloud/certs/www2.somethelse.eu.crt crt > /etc/ssl/cloud/certs/www2.somethelse.fr.crt crt > /etc/ssl/cloud/certs/www2.somethelse.net.crt crt > /etc/ssl/cloud/certs/www2.somethelse.org.crt crt > /etc/ssl/cloud/certs/prod-appapp4.this-company.net.crt crt > /etc/ssl/cloud/certs/appapp4.this-company.net.crt > > (this line is edited but is as long as the original one) > > This is how haproxy complains at restart: > > [ALERT] 163/095929 (3094) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:180]: line too long, truncating at > word 65, position 1438: ... > [ALERT] 163/095929 (3094) : parsing > [/etc/haproxy/extra/cloudcontroller.cfg:180] : 'bind *:443' : 'crt' : > missing certificate location > [ALERT] 163/095929 (3094) : Error(s) found in configuration file : > /etc/haproxy/extra/cloudcontroller.cfg > > > As it first truncates the bind content, it then without surprises fails to > load. > > Is this affordable just to increase the bind argument size limit, maybe to > something enoughly large that no one can reach this limit ? > > I think the usual way to handle that is to just specify the directory in "crt" and let haproxy load all the certs from that location. If you want to have a default certificate used when no SNI is provided or when SNI is provided but a cert is not found for it, then name the default cert using "crt" and then load the read with "crt /etc/haproxy/cloud/certs/". The crt-list option might be interesting for you as well. -Bryan
Re: bug: long bind lines causes config not to be loaded
Sorry for responding in the wrong thread, somehow I'm seeing two threads for this (and another) message. Not sure if it's gmail or the list that's duplicating threads today. -Bryan On Fri, Jun 13, 2014 at 10:48 AM, Bryan Talbot wrote: > On Fri, Jun 13, 2014 at 1:08 AM, kiorky wrote: > >> just forgot to include the version: HA-Proxy version 1.5-dev25-a339395 >> 2014/05/10 >> >> On 13/06/2014 10:04, kiorky wrote: >> >> Hi we use here a generator for haproxy configs and this one generates >> amongst all https frontend using SNI to redirect to endspoints. >> Basically, we host lot of VMS and the host is NATing/redirecting every >> served domain to the underlying VM and when we use https. >> In other words, it terminates SSL on the haproxy front and we are using a >> certicate per VM. >> Technically, this was as simple as adding a crt for each vm... >> This setup worked fine and without a glitch for a time, but it's falling >> on one host as the generated bind line seems to be too long: >> >> bind *:443 ssl crt /etc/ssl/cloud/certs/ovh-r5-2.this-company.net.crt crt >> /etc/ssl/cloud/certs/prod-appapp1.this-company.net.crt crt >> /etc/ssl/cloud/certs/appapp1.this-company.net.crt crt >> /etc/ssl/cloud/certs/prod-somethelse.this-company.net.crt crt >> /etc/ssl/cloud/certs/someth-else.be.crt crt >> /etc/ssl/cloud/certs/someth-else.com.crt crt >> /etc/ssl/cloud/certs/someth-else.eu.crt crt >> /etc/ssl/cloud/certs/someth-else.fr.crt crt >> /etc/ssl/cloud/certs/someth-else.mobi.crt crt >> /etc/ssl/cloud/certs/someth-else.net.crt crt >> /etc/ssl/cloud/certs/someth-else.org.crt crt >> /etc/ssl/cloud/certs/somethelse.be.crt crt >> /etc/ssl/cloud/certs/somethelse.com.crt crt >> /etc/ssl/cloud/certs/somethelse.eu.crt crt >> /etc/ssl/cloud/certs/somethelse.fr.crt crt >> /etc/ssl/cloud/certs/somethelse.mobi.crt crt >> /etc/ssl/cloud/certs/somethelse.net.crt crt >> /etc/ssl/cloud/certs/somethelse.org.crt crt >> /etc/ssl/cloud/certs/e-cov.somethelse.net.crt crt >> /etc/ssl/cloud/certs/appappapp3.somethelse.net.crt crt >> /etc/ssl/cloud/certs/www.someth-else.be.crt crt >> /etc/ssl/cloud/certs/www.someth-else.com.crt crt >> /etc/ssl/cloud/certs/www.someth-else.eu.crt crt >> /etc/ssl/cloud/certs/www.someth-else.fr.crt crt >> /etc/ssl/cloud/certs/www.someth-else.mobi.crt crt >> /etc/ssl/cloud/certs/www.someth-else.org.crt crt >> /etc/ssl/cloud/certs/www.somethelse.be.crt crt >> /etc/ssl/cloud/certs/www.somethelse.com.crt crt >> /etc/ssl/cloud/certs/www.somethelse.eu.crt crt >> /etc/ssl/cloud/certs/www.somethelse.fr.crt crt >> /etc/ssl/cloud/certs/www.somethelse.mobi.crt crt >> /etc/ssl/cloud/certs/www.somethelse.net.crt crt >> /etc/ssl/cloud/certs/www.somethelse.org.crt crt >> /etc/ssl/cloud/certs/www2.somethelse.com.crt crt >> /etc/ssl/cloud/certs/www2.somethelse.eu.crt crt >> /etc/ssl/cloud/certs/www2.somethelse.fr.crt crt >> /etc/ssl/cloud/certs/www2.somethelse.net.crt crt >> /etc/ssl/cloud/certs/www2.somethelse.org.crt crt >> /etc/ssl/cloud/certs/prod-appapp4.this-company.net.crt crt >> /etc/ssl/cloud/certs/appapp4.this-company.net.crt >> >> (this line is edited but is as long as the original one) >> >> This is how haproxy complains at restart: >> >> [ALERT] 163/095929 (3094) : parsing >> [/etc/haproxy/extra/cloudcontroller.cfg:180]: line too long, truncating at >> word 65, position 1438: ... >> [ALERT] 163/095929 (3094) : parsing >> [/etc/haproxy/extra/cloudcontroller.cfg:180] : 'bind *:443' : 'crt' : >> missing certificate location >> [ALERT] 163/095929 (3094) : Error(s) found in configuration file : >> /etc/haproxy/extra/cloudcontroller.cfg >> >> >> As it first truncates the bind content, it then without surprises fails >> to load. >> >> Is this affordable just to increase the bind argument size limit, maybe >> to something enoughly large that no one can reach this limit ? >> >> > > I think the usual way to handle that is to just specify the directory in > "crt" and let haproxy load all the certs from that location. > > If you want to have a default certificate used when no SNI is provided or > when SNI is provided but a cert is not found for it, then name the default > cert using "crt" and then load the read with "crt > /etc/haproxy/cloud/certs/". > > The crt-list option might be interesting for you as well. > > -Bryan > > >
Re: bug: long bind lines causes config not to be loaded
Hi Bryan, On Fri, Jun 13, 2014 at 10:51:04AM -0700, Bryan Talbot wrote: > Sorry for responding in the wrong thread, somehow I'm seeing two threads > for this (and another) message. Not sure if it's gmail or the list that's > duplicating threads today. It's neither, it's kiorky who responded to himself in parallel to another response, so that effectively lead to two parallel threads :-) Willy
Almost there...
Hi all, just a quick update at the end of the week. I think we're about to have everything that was pending merged. Emeric and Dirkjan at github are finishing a basic support for OCSP Stapling which we'd prefer to merge before the release in case we figure out that we need a smarter way to configure the CA files now. I might study what it costs to implement the "show stats detail" we wanted a long time ago which will allow quotes in the CSV format so that we can later add more indicators if needed : at this point, the HTML is much more complete than the CSV and that's a shame :-/ If you think something is missing for 1.5 (ie: something which might cause a config change or an interface change if done later), please speak up now. If everything goes well, we'll probably be done early next week. Time to buy a bottle of champagne and put it in the office's fridge I guess :-) Have a nice week-end, Willy
Re: question on tcp persistence via source ip
Hi, I'm not aware of a way to achieve what you want exactly. The stick table expiry works best with something like HTTP where connections are not that long so fresh connections keep refreshing the timer. In the case of SSH or RDP you have 1 potentially very long connection so the only option you have is to use a very long expire timeout. An example being RDP where I regularly recommend 12 hours or so for expire time... Aaron On 13 June 2014 02:52, Hailing Xu wrote: > Hello haproxy geeks, > > I am trying to use haproxy in the following scenario that persistent tcp > connections using source ip. > > The client establishes a tcp connection (such as ssh for e.g),to vip, and > vip allocates a real server rs1. I can see the stick table entry via cli. > When this tcp session keeps a long time, during this period, the relevant > stick table entry's expiration time is always decresing, until it is > removed for timeout. But at this time point the existing tcp connection is > still alive. If I close the connection, and start a new one, it is > allocated a different real server, for round robin and no stick table entry > matches. > > My question is "is it normal that timeout the stick entry even there is > still a session alive from that client?" > if yes, why it is designed such a way. Is it more comprehensible that the > stick table starts timing out after no session from that client. > if no, is there any configuration in haproxy I missed to avoid the stick > table timeout in case there still existing live session from that client. > > Thanks a lot for your help and information. > Hailing. >
Re: question on tcp persistence via source ip
I agree with Aaron. the expire period in the stick table should cover at least the expected work period. This is also how I setup them. Baptiste On Fri, Jun 13, 2014 at 10:40 PM, Aaron West wrote: > Hi, > > I'm not aware of a way to achieve what you want exactly. > > The stick table expiry works best with something like HTTP where connections > are not that long so fresh connections keep refreshing the timer. > > In the case of SSH or RDP you have 1 potentially very long connection so the > only option you have is to use a very long expire timeout. An example being > RDP where I regularly recommend 12 hours or so for expire time... > > Aaron > > > On 13 June 2014 02:52, Hailing Xu wrote: >> >> Hello haproxy geeks, >> >> I am trying to use haproxy in the following scenario that persistent tcp >> connections using source ip. >> >> The client establishes a tcp connection (such as ssh for e.g),to vip, and >> vip allocates a real server rs1. I can see the stick table entry via cli. >> When this tcp session keeps a long time, during this period, the relevant >> stick table entry's expiration time is always decresing, until it is removed >> for timeout. But at this time point the existing tcp connection is still >> alive. If I close the connection, and start a new one, it is allocated a >> different real server, for round robin and no stick table entry matches. >> >> My question is "is it normal that timeout the stick entry even there is >> still a session alive from that client?" >> if yes, why it is designed such a way. Is it more comprehensible that the >> stick table starts timing out after no session from that client. >> if no, is there any configuration in haproxy I missed to avoid the stick >> table timeout in case there still existing live session from that client. >> >> Thanks a lot for your help and information. >> Hailing. > >
