From: Ilya Shipitsin Date: Sat, 14 Mar 2020 12:47:28 +0000 (+0500) Subject: DOC: assorted typo fixes in the documentation X-Git-Tag: v2.2-dev5~34 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=1fae8db7b7a9db2a7442674232f1382205947abb;p=thirdparty%2Fhaproxy.git DOC: assorted typo fixes in the documentation This is the fourth round of cleanups in various docs --- diff --git a/contrib/modsecurity/README b/contrib/modsecurity/README index 8031389db4..8e74016fce 100644 --- a/contrib/modsecurity/README +++ b/contrib/modsecurity/README @@ -1,7 +1,7 @@ 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 @@ -24,8 +24,8 @@ the Apache dependencies are installed on the system. 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 --------------------- @@ -113,7 +113,7 @@ Modsecurity bugs: - 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. diff --git a/contrib/prometheus-exporter/README b/contrib/prometheus-exporter/README index a63102028a..1c5a992410 100644 --- a/contrib/prometheus-exporter/README +++ b/contrib/prometheus-exporter/README @@ -4,14 +4,14 @@ PROMEX: A Prometheus exporter for HAProxy 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" @@ -46,7 +46,7 @@ applet, all metrics are not grouped by service (proxy, listener or server). With 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. @@ -99,7 +99,7 @@ Exported metrics | 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. | diff --git a/contrib/spoa_server/README b/contrib/spoa_server/README index fa039c1afc..341f5f978d 100644 --- a/contrib/spoa_server/README +++ b/contrib/spoa_server/README @@ -79,7 +79,7 @@ Main process: 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 ? diff --git a/doc/internals/initcalls.txt b/doc/internals/initcalls.txt index 4558c94797..3a7b14b8ed 100644 --- a/doc/internals/initcalls.txt +++ b/doc/internals/initcalls.txt @@ -62,7 +62,7 @@ make sure to respect this ordering when adding new ones. 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. @@ -110,7 +110,7 @@ make sure to respect this ordering when adding new 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. @@ -123,7 +123,7 @@ make sure to respect this ordering when adding new 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)()) @@ -148,7 +148,7 @@ make sure to respect this ordering when adding new ones. 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 *)) @@ -160,7 +160,7 @@ make sure to respect this ordering when adding new ones. 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 *))