MEDIUM: monitor: simplify handling of monitor-net and mode health

We were having several different behaviours with monitor-net and
"mode health" :
  - monitor-net on TCP connections was evaluated just after accept(),
    did not count a connection on the frontend and were not subject
    to tcp-request connection rules, and caused an immediate close().

  - monitor-net in HTTP mode was evaluated once the session was
    accepted (eg: on top of SSL), returned "HTTP/1.0 200 OK\r\n\r\n"
    over the connection's data layer and instanciated a session which
    was responsible for closing this connection. A connection AND a
    session were counted for the frontend ;

  - "mode health" with "option httpchk" would do exactly the same as
    monitor-net in HTTP mode ;

  - "mode health" without "option httpchk" would do the same as above
    except that "OK" was returned instead of "HTTP/1.0 200 OK\r\n\r\n".

None of them took care of cleaning the input buffer, sometimes resulting
in a TCP reset to be emitted after the last packet if a request was received
over the connection.

Given the inconsistencies and the complexity in keeping all these features
handled at the right position, we now slightly changed the way they are
handled :

  - all of them are handled just after the "tcp-request connection" rules,
    so that all of them may be blocked using such rules, offering more
    flexibility and consistency ;

  - no connection handshake is performed anymore for non-TCP modes

  - all of them send the response as raw data over the socket, there is no
    more difference between TCP and HTTP mode for example (these rules were
    never meant to be served over SSL connections and were never documented
    as able to do that).

  - any possible pending data on the incoming socket is drained before the
    response is sent, in order to avoid the risk of a reset.

  - none of them exactly did what was documented !

This results in more consistent, more flexible and more accurate handling of
monitor rules, with smaller and more robust code.

diff --git a/doc/configuration.txt b/doc/configuration.txt
index 3788ac025ac27dce0c1789f8db74dc1b1ff28ae7..ae830c0d6cb860785f1cc14a3736da763e41e1b5 100644 (file)
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -2628,11 +2628,13 @@ mode { tcp|http|health }
               brings HAProxy most of its value.
 
     health    The instance will work in "health" mode. It will just reply "OK"
-              to incoming connections and close the connection. Nothing will be
-              logged. This mode is used to reply to external components health
-              checks. This mode is deprecated and should not be used anymore as
-              it is possible to do the same and even better by combining TCP or
-              HTTP modes with the "monitor" keyword.
+              to incoming connections and close the connection. Alternatively,
+              If the "httpchk" option is set, "HTTP/1.0 200 OK" will be sent
+              instead. Nothing will be logged in either case. This mode is used
+              to reply to external components health checks. This mode is
+              deprecated and should not be used anymore as it is possible to do
+              the same and even better by combining TCP or HTTP modes with the
+              "monitor" keyword.
 
   When doing content switching, it is mandatory that the frontend and the
   backend are in the same mode (generally HTTP), otherwise the configuration
@@ -2701,13 +2703,16 @@ monitor-net <source>
   accepted, the following response will be sent without waiting for a request,
   then the connection will be closed : "HTTP/1.0 200 OK". This is normally
   enough for any front-end HTTP probe to detect that the service is UP and
-  running without forwarding the request to a backend server.
-
-  Monitor requests are processed very early. It is not possible to block nor
-  divert them using ACLs. They cannot be logged either, and it is the intended
-  purpose. They are only used to report HAProxy's health to an upper component,
-  nothing more. Right now, it is not possible to set failure conditions on
-  requests caught by "monitor-net".
+  running without forwarding the request to a backend server. Note that this
+  response is sent in raw format, without any transformation. This is important
+  as it means that it will not be SSL-encrypted on SSL listeners.
+
+  Monitor requests are processed very early, just after tcp-request connection
+  ACLs which are the only ones able to block them. These connections are short
+  lived and never wait for any data from the client. They cannot be logged, and
+  it is the intended purpose. They are only used to report HAProxy's health to
+  an upper component, nothing more. Please note that "monitor fail" rules do
+  not apply to connections intercepted by "monitor-net".
 
   Last, please note that only one "monitor-net" statement can be specified in
   a frontend. If more than one is found, only the last one will be considered.

diff --git a/src/frontend.c b/src/frontend.c
index b2b6b1141c792146eceac7fb8c4969fa92191f7e..3bfd1e577f04b6969296d0c9a364beca1e10a2ec 100644 (file)
--- a/src/frontend.c
+++ b/src/frontend.c
@@ -197,27 +197,6 @@ int frontend_accept(struct session *s)
        s->req->rto = s->fe->timeout.client;
        s->rep->wto = s->fe->timeout.client;
 
-       if (unlikely((s->fe->mode == PR_MODE_HTTP && (s->flags & SN_MONITOR)) ||
-                    (s->fe->mode == PR_MODE_HEALTH && ((s->fe->options2 & PR_O2_CHK_ANY) == PR_O2_HTTP_CHK)))) {
-               /* Either we got a request from a monitoring system on an HTTP instance,
-                * or we're in health check mode with the 'httpchk' option enabled. In
-                * both cases, we return a fake "HTTP/1.0 200 OK" response and we exit.
-                */
-               struct chunk msg;
-               chunk_initstr(&msg, "HTTP/1.0 200 OK\r\n\r\n");
-               stream_int_retnclose(&s->si[0], &msg); /* forge a 200 response */
-               s->req->analysers = 0;
-               s->task->expire = s->rep->wex;
-               fd_stop_recv(cfd);
-       }
-       else if (unlikely(s->fe->mode == PR_MODE_HEALTH)) {  /* health check mode, no client reading */
-               struct chunk msg;
-               chunk_initstr(&msg, "OK\n");
-               stream_int_retnclose(&s->si[0], &msg); /* forge an "OK" response */
-               s->req->analysers = 0;
-               s->task->expire = s->rep->wex;
-               fd_stop_recv(cfd);
-       }
        /* everything's OK, let's go on */
        return 1;
 

diff --git a/src/listener.c b/src/listener.c
index d704b42448dd4ed999634333b7d5cd0630bd41f1..f63f9bae3252a7ea8909708154f29075a34ac22b 100644 (file)
--- a/src/listener.c
+++ b/src/listener.c
@@ -345,18 +345,6 @@ void listener_accept(int fd)
                        }
                }
 
-               /* if this connection comes from a known monitoring system, we want to ignore
-                * it as soon as possible, which means closing it immediately if it is only a
-                * TCP-based monitoring check.
-                */
-               if (unlikely((l->options & LI_O_CHK_MONNET) &&
-                            (p->mode == PR_MODE_TCP) &&
-                            addr.ss_family == AF_INET &&
-                            (((struct sockaddr_in *)&addr)->sin_addr.s_addr & p->mon_mask.s_addr) == p->mon_net.s_addr)) {
-                       close(cfd);
-                       continue;
-               }
-
                if (unlikely(cfd >= global.maxsock)) {
                        send_log(p, LOG_EMERG,
                                 "Proxy %s reached the configured maximum connection limit. Please check the global 'maxconn' value.\n",

diff --git a/src/session.c b/src/session.c
index b98b87825de4c3bc4b770de1f6b64fd05bf345fb..be25ccf7e4974498ab535b1cdfad48da2a7a79b8 100644 (file)
--- a/src/session.c
+++ b/src/session.c
@@ -105,17 +105,6 @@ int session_accept(struct listener *l, int cfd, struct sockaddr_storage *addr)
 
        proxy_inc_fe_conn_ctr(l, p);
 
-       /* if this session comes from a known monitoring system, we want to ignore
-        * it as soon as possible, which means closing it immediately for TCP, but
-        * cleanly.
-        */
-       if (unlikely((l->options & LI_O_CHK_MONNET) &&
-                    addr->ss_family == AF_INET &&
-                    (((struct sockaddr_in *)addr)->sin_addr.s_addr & p->mon_mask.s_addr) == p->mon_net.s_addr)) {
-               s->flags |= SN_MONITOR;
-               s->logs.logwait = 0;
-       }
-
        /* now evaluate the tcp-request layer4 rules. Since we expect to be able
         * to abort right here as soon as possible, we check the rules before
         * even initializing the stream interfaces.
@@ -127,16 +116,44 @@ int session_accept(struct listener *l, int cfd, struct sockaddr_storage *addr)
                goto out_free_session;
        }
 
+       /* Adjust some socket options */
+       if (unlikely(fcntl(cfd, F_SETFL, O_NONBLOCK) == -1))
+               goto out_free_session;
+
+       /* monitor-net and health mode are processed immediately after TCP
+        * connection rules. This way it's possible to block them, but they
+        * never use the lower data layers, they send directly over the socket,
+        * as they were designed for. We first flush the socket receive buffer
+        * in order to avoid emission of an RST by the system. We ignore any
+        * error.
+        */
+       if (unlikely((p->mode == PR_MODE_HEALTH) ||
+                    ((l->options & LI_O_CHK_MONNET) &&
+                     addr->ss_family == AF_INET &&
+                     (((struct sockaddr_in *)addr)->sin_addr.s_addr & p->mon_mask.s_addr) == p->mon_net.s_addr))) {
+               /* we have 4 possibilities here :
+                *  - HTTP mode, from monitoring address => send "HTTP/1.0 200 OK"
+                *  - HEALTH mode with HTTP check => send "HTTP/1.0 200 OK"
+                *  - HEALTH mode without HTTP check => just send "OK"
+                *  - TCP mode from monitoring address => just close
+                */
+               recv(cfd, trash, trashlen, 0&MSG_DONTWAIT);
+               if (p->mode == PR_MODE_HTTP ||
+                   (p->mode == PR_MODE_HEALTH && (p->options2 & PR_O2_CHK_ANY) == PR_O2_HTTP_CHK))
+                       send(cfd, "HTTP/1.0 200 OK\r\n\r\n", 19, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_MORE);
+               else if (p->mode == PR_MODE_HEALTH)
+                       send(cfd, "OK\n", 3, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_MORE);
+               ret = 0;
+               goto out_free_session;
+       }
+
+
        /* wait for a PROXY protocol header */
        if (l->options & LI_O_ACC_PROXY) {
                s->si[0].conn.flags |= CO_FL_ACCEPT_PROXY;
                conn_sock_want_recv(&s->si[0].conn);
        }
 
-       /* Adjust some socket options */
-       if (unlikely(fcntl(cfd, F_SETFL, O_NONBLOCK) == -1))
-               goto out_free_session;
-
        if (unlikely((t = task_new()) == NULL))
                goto out_free_session;