ModSecurity for HAProxy
-----------------------
-This is a third party deamon which speaks SPOE. It gives requests send by HAProxy
+This is a third party daemon which speaks SPOE. It gives requests send by HAProxy
to ModSecurity and returns the verdict.
Compilation
cp standalone/*.h $PWD/INSTALL/include
cp apache2/*.h $PWD/INSTALL/include
-Note that this compilation method works, but is a litle bit rustic. I can't
-deal with Lua, I supposed that is a dependecies problem on my computer.
+Note that this compilation method works, but is a little bit rustic. I can't
+deal with Lua, I supposed that is a dependencies problem on my computer.
Start the service
---------------------
- rc = apr_global_mutex_create(&msce->auditlog_lock, NULL, APR_LOCK_DEFAULT, mp);
+ rc = apr_global_mutex_create(&msce->auditlog_lock, NULL, APR_LOCK_PROC_PTHREAD, mp);
-* Configuration file loaded with wilcard (eg. Include rules/*.conf), are loaded
+* Configuration file loaded with wildcard (eg. Include rules/*.conf), are loaded
in reverse alphabetical order. You can found a patch below. The ModSecurity
team ignored this patch.
Prometheus is a monitoring and alerting system. More and more people use it to
monitor their environment (this is written February 2019). It collects metrics
from monitored targets by scraping metrics HTTP endpoints on these targets. For
-HAProxy, The Prometheus team offically supports an exporter written in Go
+HAProxy, The Prometheus team officially supports an exporter written in Go
(https://github.com/prometheus/haproxy_exporter). But it requires an extra
software to deploy and monitor. PROMEX, on its side, is a built-in Prometheus
exporter for HAProxy. It was developed as a service and is directly available in
HAProxy, like the stats applet.
However, PROMEX is not built by default with HAProxy. It is provided as an extra
-component for everyone want to use it. So you need to explicity build HAProxy
+component for everyone want to use it. So you need to explicitly build HAProxy
with the PROMEX service, using the Makefile variable "EXTRA_OBJS". For instance:
> make TARGET=linux-glibc EXTRA_OBJS="contrib/prometheus-exporter/service-prometheus.o"
PROMEX, all lines for a given metric are provided as one single group. So
instead of collecting all metrics for a proxy before moving to the next one, we
must loop on all proxies for each metric. Same for the servers. Thus, it will
-spend much more ressources to produce the Prometheus metrics than the CSV export
+spend much more resources to produce the Prometheus metrics than the CSV export
through the stats page. To give a comparison order, quick benchmarks shown that
a PROMEX dump is 5x slower and 20x more verbose than a CSV export.
| haproxy_process_pool_used_bytes | Total amount of memory used in pools (in bytes). |
| haproxy_process_pool_failures_total | Total number of failed pool allocations. |
| haproxy_process_max_fds | Maximum number of open file descriptors; 0=unset. |
-| haproxy_process_max_sockets | Maximum numer of open sockets. |
+| haproxy_process_max_sockets | Maximum number of open sockets. |
| haproxy_process_max_connections | Maximum number of concurrent connections. |
| haproxy_process_hard_max_connections | Initial Maximum number of concurrent connections. |
| haproxy_process_current_connections | Number of active sessions. |
Python:
- * Improve repporting: Catch python error message and repport it in the right
+ * Improve reporting: Catch python error message and report it in the right
place. Today the error are dumped on stdout. How using syslog for logging
stack traces ?
are serialized by the init_mutex, so that locking is not necessary in these
functions. There is no relation between the thread numbers and the callback
ordering. The function is expected to return non-zero on success, or zero on
- failure. A failure will make the process emit a succint error message and
+ failure. A failure will make the process emit a succinct error message and
immediately exit. See also hap_register_per_thread_free() for functions
called after these ones.
current one, the sequence of _alloc() and _init() calls will be atomic. There
is no relation between the thread numbers and the callback ordering. The
function is expected to return non-zero on success, or zero on failure. A
- failure will make the process emit a succint error message and immediately
+ failure will make the process emit a succinct error message and immediately
exit. See also hap_register_per_thread_alloc() for functions called before
these ones.
that would preferably not be done on the fly to avoid inducing extra time to
a pure configuration check. Threads are not yet started so no protection is
required. The function is expected to return non-zero on success, or zero on
- failure. A failure will make the process emit a succint error message and
+ failure. A failure will make the process emit a succinct error message and
immediately exit.
- void hap_register_post_deinit(void (*fct)())
worth being aware that such a function must be careful not to waste too much
time in order not to significantly slow down configurations with tens of
thousands of backends. The function is expected to return non-zero on
- success, or zero on failure. A failure will make the process emit a succint
+ success, or zero on failure. A failure will make the process emit a succinct
error message and immediately exit.
- void hap_register_post_server_check(int (*fct)(struct server *))
careful not to waste too much time in order not to significantly slow down
configurations with tens of thousands of servers. The function is expected
to return non-zero on success, or zero on failure. A failure will make the
- process emit a succint error message and immediately exit.
+ process emit a succinct error message and immediately exit.
- void hap_register_proxy_deinit(void (*fct)(struct proxy *))
projects / thirdparty / haproxy.git / commitdiff
