Inhaltsverzeichnis
HAProxy ArchLinux
HAProxy ist ein kostenloser, sehr schneller und zuverlässiger „Reverse-Proxy“, der Hochverfügbarkeit, Lastverteilung und als „Proxy“ für TCP- und HTTP-basierte Anwendungen agieren kann.
Er eignet sich besonders für sehr stark frequentierte Websites und betreibt einen erheblichen Teil der weltweit meistbesuchten Websites. Im Laufe der Jahre hat er sich zum De-facto-Standard unter den „Open-Source-Load-Balancern“ entwickelt, wird inzwischen mit den meisten gängigen Linux-Distributionen ausgeliefert und wird häufig standardmässig in „Cloud-Plattformen“ eingesetzt.
| Beschreibung | Externer Link |
|---|---|
| Homepage | https://www.haproxy.org/ |
| Dokumentation | http://docs.haproxy.org/ |
| AchLinux-Wiki | HAProxy |
Ab hier werden zur Ausführung nachfolgender Befehle root-Rechte benötigt. Um der Benutzer root zu werden, melden Sie sich bitte als root-Benutzer am System an, oder wechseln mit nachfolgendem Befehl zum Benutzer root:
$ su - Password:
Beispiel-Szenario
Nachfolgender Testaufbau soll als Grundlage für die nachfolgende Konfiguration dienen:
┌──────────┐
https only │ Server │
┌───────────► srv030 │
│ └──────────┘
┌───────────────────────────────────┐ Redirect ┌────▼────┐
│ Browser *¹ │ http→https │ *²*³ │
│ http://srv030-apache.tachtler.net ◄──────────────► HAProxy │
│ http://srv040-apache.tachtler.net │ https only │ │
└───────────────────────────────────┘ └────▲────┘ ┌──────────┐
│ │ Server │
└───────────► srv040 │
https only └──────────┘
Erklärung:
- Anfragen vom Client/Browser können via
http(80) oderhttps(443) gestellt werden. - Der HAProxy leitet nur
https(443)-Anfragen an das „Backend“ weiter, so das erneut einehttps(443)-Verschlüsselung erfolgt.
Installation
Zur Installation von HAProxy wird nachfolgendes Paket benötigt:
Mit nachfolgendem Befehl, wird das Pakete haproxy installiert:
# pacman --noconfirm -S haproxy
HINWEIS - Nachfolgender Hinweis wurde bei der Installation ausgegeben und sollte unbedingt beachtet werden:
==> The example config chroots HAProxy, meaning that logging to journald won't work.
Either disable chrooting, use rsyslog, or bind /run/systemd/journal/dev-log into the chroot.
Mit nachfolgendem Befehl kann überprüft werden, welche Inhalte mit den Paket haproxy installiert wurden.
# pacman -Qil haproxy
Dienst/Daemon-Start einrichten
Um einen HAProxy, welcher als Dienst/Daemon als Hintergrundprozess läuft, auch nach einem Neustart des Servers zur Verfügung zu haben, soll der Dienst/Daemon mit dem Server mit gestartet werden, was mit nachfolgendem Befehl realisiert werden kann:
# systemctl enable haproxy.service Created symlink /etc/systemd/system/multi-user.target.wants/haproxy.service → /usr/lib/systemd/system/haproxy.service.
Eine Überprüfung, ob beim Neustart des Server der haproxy-Dienst/Daemon wirklich mit gestartet wird, kann mit nachfolgendem Befehl erfolgen und sollte eine Anzeige, wie ebenfalls nachfolgend dargestellt ausgeben:
# systemctl list-unit-files --type=service | grep -e haproxy.service haproxy.service enabled disabled
bzw.
# systemctl is-enabled haproxy.service enabled
iptables/ip6tables Regeln
Damit der HAProxy auch erreichbar ist und nicht die Proxy-Anfragen vom Paketfilter iptables blockiert werden, müssen nachfolgende Regeln zum iptables-Regelwerk hinzugefügt werden.
Um die aktuellen iptables-Regeln erweitern zu können, sollten diese erst einmal aufgelistet werden, was mit nachfolgendem Befehl durchgeführt werden kann:
# iptables -L -nv --line-numbers Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 1169 2101K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 2 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 3 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 4 1 60 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 5 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 5 prefix "REC-INP Defend " 6 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset 7 0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 8 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 917 packets, 84944 bytes) num pkts bytes target prot opt in out source destination
Nachfolgende Befehle, fügen folgende iptables-Regeln dem iptables-Regelwerk nach der Position 4 hinzu, ohne das der Paketfilter angehalten werden muss:
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT
und hier die Befehle:
# iptables -I INPUT 5 -p tcp --dport 80 -j ACCEPT # iptables -I INPUT 5 -p tcp --dport 443 -j ACCEPT
Ein erneute Abfrage des iptables-Regelwerts, sollte dann nachfolgend dargestellte Ausgabe ergeben, was mit folgendem Befehl durchgeführt werden kann:
# iptables -L -nv --line-numbers Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 1202 2103K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 2 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 3 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 4 1 60 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 5 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 6 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 7 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 5 prefix "REC-INP Defend " 8 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset 9 0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 10 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 7 packets, 936 bytes) num pkts bytes target prot opt in out source destination
Die neuen Zeilen sind an Position 5 (INPUT) und Position 6 (INPUT) zu sehen, hier nachfolgend zur Verdeutlichung noch einmal dargestellt (nur relevanter Ausschnitt):
... 5 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 6 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 ...
Um diese iptables-Regel dauerhaft, auch nach einem Neustart des Server, weiterhin im iptables-Regelwerk zu speichern, muss nachfolgend dargestellter Befehl abschliessend noch ausgeführt werden:
# /usr/sbin/iptables-save > /etc/iptables/iptables.rules
Nachfolgender Befehl kann dazu verwendet werden, um zu überprüfen, ob das iptables-Regelwerk auch korrekt gespeichert wurde:
# cat /etc/iptables/iptables.rules # Generated by iptables-save v1.8.7 on Wed Mar 31 10:13:23 2022 *filter :INPUT DROP [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [13:3332] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT -A INPUT -j LOG --log-prefix "REC-INP Defend " --log-level 5 -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -j REJECT --reject-with icmp-proto-unreachable COMMIT # Completed on Wed Mar 31 10:13:23 2022 # Generated by iptables-save v1.8.7 on Wed Mar 31 10:13:23 2022 *nat :PREROUTING ACCEPT [5:352] :INPUT ACCEPT [1:60] :OUTPUT ACCEPT [8:577] :POSTROUTING ACCEPT [8:577] COMMIT # Completed on Wed Mar 31 10:13:23 2022 # Generated by iptables-save v1.8.7 on Wed Mar 31 10:13:23 2022 *mangle :PREROUTING ACCEPT [1216:2104461] :INPUT ACCEPT [1212:2104169] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [944:91396] :POSTROUTING ACCEPT [944:91396] COMMIT # Completed on Wed Mar 31 10:13:23 2022
Um die aktuellen ip6tables-Regeln erweitern zu können, sollten diese erst einmal aufgelistet werden, was mit nachfolgendem Befehl durchgeführt werden kann:
# ip6tables -nvL --line-numbers Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT all * * ::/0 ::/0 ctstate RELATED,ESTABLISHED 2 0 0 ACCEPT icmp * * ::/0 ::/0 3 0 0 ACCEPT all lo * ::/0 ::/0 4 0 0 ACCEPT tcp * * ::/0 ::/0 tcp dpt:22 5 0 0 LOG all * * ::/0 ::/0 LOG flags 0 level 5 prefix "REC-INP Defend " 6 0 0 REJECT tcp * * ::/0 ::/0 reject-with tcp-reset 7 0 0 REJECT udp * * ::/0 ::/0 reject-with icmp6-port-unreachable 8 0 0 REJECT all * * ::/0 ::/0 reject-with icmp6-addr-unreachable Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 LOG all * * ::/0 ::/0 LOG flags 0 level 5 prefix "REC-FWD Defend " 2 0 0 REJECT tcp * * ::/0 ::/0 reject-with tcp-reset 3 0 0 REJECT udp * * ::/0 ::/0 reject-with icmp6-port-unreachable 4 0 0 REJECT all * * ::/0 ::/0 reject-with icmp6-addr-unreachable Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination
Nachfolgende Befehle, fügen folgende ip6tables-Regeln dem ip6tables-Regelwerk nach der Position 4 hinzu, ohne das der Paketfilter angehalten werden muss:
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT
und hier die Befehle:
# ip6tables -I INPUT 5 -p tcp --dport 80 -j ACCEPT # ip6tables -I INPUT 6 -p tcp --dport 443 -j ACCEPT
Ein erneute Abfrage des ip6tables-Regelwerts, sollte dann nachfolgend dargestellte Ausgabe ergeben, was mit folgendem Befehl durchgeführt werden kann:
# ip6tables -nvL --line-numbers Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT all * * ::/0 ::/0 ctstate RELATED,ESTABLISHED 2 0 0 ACCEPT icmp * * ::/0 ::/0 3 0 0 ACCEPT all lo * ::/0 ::/0 4 0 0 ACCEPT tcp * * ::/0 ::/0 tcp dpt:22 5 0 0 ACCEPT tcp * * ::/0 ::/0 tcp dpt:80 6 0 0 ACCEPT tcp * * ::/0 ::/0 tcp dpt:443 7 0 0 LOG all * * ::/0 ::/0 LOG flags 0 level 5 prefix "REC-INP Defend " 8 0 0 REJECT tcp * * ::/0 ::/0 reject-with tcp-reset 9 0 0 REJECT udp * * ::/0 ::/0 reject-with icmp6-port-unreachable 10 0 0 REJECT all * * ::/0 ::/0 reject-with icmp6-addr-unreachable Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 LOG all * * ::/0 ::/0 LOG flags 0 level 5 prefix "REC-FWD Defend " 2 0 0 REJECT tcp * * ::/0 ::/0 reject-with tcp-reset 3 0 0 REJECT udp * * ::/0 ::/0 reject-with icmp6-port-unreachable 4 0 0 REJECT all * * ::/0 ::/0 reject-with icmp6-addr-unreachable Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination
Die neuen Zeilen sind an Position 5 (INPUT) und Postition 6 (INTPUT) zu sehen, hier nachfolgend zur Verdeutlichung noch einmal dargestellt (nur relevanter Ausschnitt):
... 5 0 0 ACCEPT tcp * * ::/0 ::/0 tcp dpt:80 6 0 0 ACCEPT tcp * * ::/0 ::/0 tcp dpt:443 ...
Um diese ip6tables-Regel dauerhaft, auch nach einem Neustart des Server, weiterhin im ip6tables-Regelwerk zu speichern, muss nachfolgend dargestellter Befehl abschließend noch ausgeführt werden:
# /usr/sbin/ip6tables-save > /etc/iptables/ip6tables.rules
Nachfolgender Befehl kann dazu verwendet werden, um zu überprüfen, ob das ip6tables-Regelwerk auch korrekt gespeichert wurde:
# cat /etc/iptables/ip6tables.rules # Generated by ip6tables-save v1.8.7 on Wed Mar 31 10:15:10 2022 *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT # Completed on Wed Mar 31 10:15:10 2022 # Generated by ip6tables-save v1.8.7 on Wed Mar 31 10:15:10 2022 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT -A INPUT -j LOG --log-prefix "REC-INP Defend " --log-level 5 -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -p udp -j REJECT --reject-with icmp6-port-unreachable -A INPUT -j REJECT --reject-with icmp6-addr-unreachable -A FORWARD -j LOG --log-prefix "REC-FWD Defend " --log-level 5 -A FORWARD -p tcp -j REJECT --reject-with tcp-reset -A FORWARD -p udp -j REJECT --reject-with icmp6-port-unreachable -A FORWARD -j REJECT --reject-with icmp6-addr-unreachable COMMIT # Completed on Wed Mar 31 10:15:10 2022 # Generated by ip6tables-save v1.8.7 on Wed Mar 31 10:15:10 2022 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT # Completed on Wed Mar 31 10:15:10 2022
Basis-Konfiguration: /etc/haproxy/haproxy.cfg
Nachfolgende Konfigurationsschritte sollen eine grundlegende Konfiguration des HAProxy darstellen und erheben keinen Anspruch auf Vollständigkeit in Bezug auf die Möglichkeiten die der HAProxy bietet.
Bevor mit der Konfiguration des HAProxy begonnen werden soll, sollte eine Sicherungskopie der mitgelieferten Konfigurationsdatei mit nachfolgendem Befehl durchgeführt werden:
# cp -a /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.orig
Anschliessend kann die Konfigurationsdatei des HAProxy komplett wie folgt neu aufgebaut werden.
Basis-Konfigurationsdatei: komplett
Die Konfigurationsdatei
/etc/haproxy/haproxy.cfg
kann in nachfolgende Blöcke aufgeteilt werden, welche da sind:
| Sektion | Beschreibung |
|---|---|
global | Die Parameter sind Prozess übergreifend und oft Betriebssystem spezifisch. |
default | Setzt alle Einstellungen auf die dokumentierten Standardeinstellungen zurück und gibt diese für die Verwendung durch die Sektionen frontend, backend und listen vor. Alle Sektionen übernehmen ihre Anfangseinstellungen immer aus der default-Sektion, und zwar standardmässig von der letzten Sektion, welche vor der neu erstellten Sektion erscheint. |
userlist | Es ist möglich, den Zugriff auf die Bereiche frontend, backend und listen oder auf http-Statistiken zu kontrollieren, indem nur authentifizierte und autorisierte Benutzer zugelassen werden. Um dies zu tun, ist es erforderlich, mindestens eine Benutzerliste zu erstellen und Benutzer zu definieren. |
mailers | Es ist möglich, E-Mail-Benachrichtigungen zu senden, wenn sich der Status von Servern ändert. |
cache | HAProxy stellt einen Cache zur Verfügung, der für die Zwischenspeicherung von kleinen Objekten (favicon.ico, css uvm.) konzipiert wurde. Es handelt sich um einen minimalistischen, wartungsarmen Cache, der im RAM läuft. |
frontend | Beschreibt eine Reihe von Sockets, die Client-Verbindungen annehmen. |
backend | Beschreibt eine Reihe von Servern, mit denen sich der HAProxy verbindet um eingehende Verbindungen weiterzuleiten. |
listen | Definiert einen vollständigen Proxy, dessen frontend- und backend-Sektion in einem Abschnitt zusammengefasst sind. Dieser ist im Allgemeinen für reinen TCP-Verkehr nützlich. |
Nachfolgend die komplette Konfigurationsdatei:
global default-path config daemon maxconn 2048 log /dev/log local0 info ssl-default-bind-options ssl-min-ver TLSv1.2 ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 stats socket /var/run/haproxy-admin.sock user root mode 600 level admin stats socket /var/run/haproxy-operator.sock user haproxy mode 600 level operator stats socket /var/run/haproxy-user.sock group wheel mode 660 level user stats maxconn 10 stats timeout 10s chroot /var/lib/haproxy user haproxy group haproxy defaults mode http timeout connect 5s timeout client 10s timeout server 10s option forwardfor option redispatch option log-separate-errors option log-health-checks option dontlognull option dontlog-normal log global userlist stats-auth group admin users admin user admin insecure-password geheim http-errors haerrors errorfile 503 /etc/haproxy/maintenance.htm frontend http-in option httplog bind ipv4@:80,ipv6@:80 alpn h2,http/1.1 redirect scheme https code 301 if !{ ssl_fc } frontend https-in option httpslog bind ipv4@:443,ipv6@:443 ssl crt haproxy.pem alpn h2,http/1.1 use_backend srv030-apache.tachtler.net if { hdr(host) -i srv030-apache.tachtler.net } use_backend phpldapadmin.tachtler.net if { hdr(host) -i phpldapadmin.tachtler.net } use_backend srv040-apache.tachtler.net if { hdr(host) -i srv040-apache.tachtler.net } use_backend repository.tachtler.net if { hdr(host) -i repository.tachtler.net } use_backend stats if { hdr(host) -i lbproxy.tachtler.net } errorfiles haerrors backend stats http-request set-path /haproxystats/%[path] if { hdr(host) -i lbproxy.tachtler.net } stats enable stats refresh 5s stats show-desc HAProxy\ for\ tachtler.net stats show-legends stats show-node haproxy.tachtler.net stats uri /haproxystats acl AUTH http_auth(stats-auth) acl AUTH_ADMIN http_auth_group(stats-auth) admin stats http-request auth realm HAProxy\ Statistics\ and\ Management unless AUTH stats admin if AUTH_ADMIN backend srv030-apache.tachtler.net option httpchk http-check connect port 443 ssl sni apache-srv030.tachtler.net alpn h2,http/1.1 http-check send meth HEAD uri /favicon.ico ver HTTP/1.1 hdr User-Agent HAProxy hdr host apache-srv030.tachtler.net http-check expect status 200-399 cookie backend:srv030-apache.tachtler.net insert indirect nocache preserve secure maxidle 30m maxlife 3h server ipv4:apache 192.168.0.30:443 source ipv4@ ssl verify required ca-file /etc/ca-certificates/extracted/ca-bundle.trust.crt alpn h2,http/1.1 check inter 3s fall 3 rise 2 port 443 observe layer7 error-limit 50 on-error mark-down cookie ipv4:srv030-apache.tachtler.net maxconn 256 server ipv6:apache fd00::dead:192:168:0:30:443 source ipv6@ ssl verify required ca-file /etc/ca-certificates/extracted/ca-bundle.trust.crt alpn h2,http/1.1 check inter 3s fall 3 rise 2 port 443 observe layer7 error-limit 50 on-error mark-down cookie ipv6:srv030-apache.tachtler.net maxconn 256 backend phpldapadmin.tachtler.net option httpchk http-check connect port 443 ssl sni phpldapadmin-srv030.tachtler.net alpn h2,http/1.1 http-check send meth HEAD uri /index.php ver HTTP/1.1 hdr User-Agent HAProxy hdr host phpldapadmin-srv030.tachtler.net http-check expect status 200-401 cookie backend:phpldapadmin.tachtler.net insert indirect nocache preserve secure maxidle 30m maxlife 3h server ipv4:apache 192.168.0.30:443 source ipv4@ ssl verify required ca-file /etc/ca-certificates/extracted/ca-bundle.trust.crt alpn h2,http/1.1 check inter 3s fall 3 rise 2 port 443 observe layer7 error-limit 50 on-error mark-down cookie ipv4:phpldapadmin.tachtler.net maxconn 256 server ipv6:apache fd00::dead:192:168:0:30:443 source ipv6@ ssl verify required ca-file /etc/ca-certificates/extracted/ca-bundle.trust.crt alpn h2,http/1.1 check inter 3s fall 3 rise 2 port 443 observe layer7 error-limit 50 on-error mark-down cookie ipv6:phpldapadmin.tachtler.net maxconn 256 backend srv040-apache.tachtler.net option httpchk http-check connect port 443 ssl sni apache-srv040.tachtler.net alpn h2,http/1.1 http-check send meth HEAD uri /favicon.ico ver HTTP/1.1 hdr User-Agent HAProxy hdr host apache-srv040.tachtler.net http-check expect status 200-399 cookie backend:srv040-apache.tachtler.net insert indirect nocache preserve secure maxidle 30m maxlife 3h server ipv4:apache 192.168.0.40:443 source ipv4@ ssl verify required ca-file /etc/ca-certificates/extracted/ca-bundle.trust.crt alpn h2,http/1.1 check inter 3s fall 3 rise 2 port 443 observe layer7 error-limit 50 on-error mark-down cookie ipv4:srv040-apache.tachtler.net maxconn 256 server ipv6:apache fd00::dead:192:168:0:40:443 source ipv6@ ssl verify required ca-file /etc/ca-certificates/extracted/ca-bundle.trust.crt alpn h2,http/1.1 check inter 3s fall 3 rise 2 port 443 observe layer7 error-limit 50 on-error mark-down cookie ipv6:srv040-apache.tachtler.net maxconn 256 backend repository.tachtler.net option httpchk http-check connect port 443 ssl sni repository-srv040.tachtler.net alpn h2,http/1.1 http-check send meth HEAD uri /favicon.ico ver HTTP/1.1 hdr User-Agent HAProxy hdr host repository-srv040.tachtler.net http-check expect status 200-399 cookie backend:repository.tachtler.net insert indirect nocache preserve secure maxidle 30m maxlife 3h server ipv4:apache 192.168.0.40:443 source ipv4@ ssl verify required ca-file /etc/ca-certificates/extracted/ca-bundle.trust.crt alpn h2,http/1.1 check inter 3s fall 3 rise 2 port 443 observe layer7 error-limit 50 on-error mark-down cookie ipv4:repository.tachtler.net maxconn 256 server ipv6:apache fd00::dead:192:168:0:40:443 source ipv6@ ssl verify required ca-file /etc/ca-certificates/extracted/ca-bundle.trust.crt alpn h2,http/1.1 check inter 3s fall 3 rise 2 port 443 observe layer7 error-limit 50 on-error mark-down cookie ipv6:repository.tachtler.net maxconn 256
Nachfolgend die Erklärungen zu den einzelnen Sektionen und den verwendeten Parametern:
Sektion: global
Die Parameter sind Prozess übergreifend und oft Betriebssystem spezifisch.
default-path config
Standardmässig lädt HAProxy alle Dateien, die durch einen relativen Pfad gekennzeichnet sind, von dem Ort, an dem der Prozess gestartet wird.
Der Parameter config gibt an, dass alle relativen Dateien aus dem Verzeichnis geladen werden sollen, das die Konfigurationsdatei enthält, hier - /etc/haproxy/.
Siehe auch: default-path
daemon
Bringt den HAProxy Dienst/Daemon dazu, im Hintergrund zu laufen. Dies ist der empfohlene Modus für den Betrieb. Dies entspricht dem Kommandozeilenargument -D. Dies kann durch das Kommandozeilenargument -db deaktiviert werden. Diese Option wird beim Start via systemd ignoriert.
Siehe auch: daemon
maxconn 2048
Setzt die maximale Anzahl der gleichzeitigen Verbindungen pro HAProxy Dienst/Daemon auf die <Anzahl>. Es entspricht dem Befehlszeilenargument -n. Der HAProxy Dienst/Daemon nimmt keine Verbindungen mehr an, wenn dieses Limit erreicht ist. Der Parameter ulimit-n wird automatisch an diesen Wert angepasst.
Siehe auch: maxconn
log /dev/log local0 info
Fügt einen globalen Syslog-Server hinzu - hier in diesem Fall den lokalen systemd-journald-Dienst/Daemon. Es können mehrere globale Log-Server definiert werden. Es werden Log-Einträge für den Start und die Beendigungen des HAProxy Dienst/Daemon sowie weitere Log-Einträge von den definierten Sektionen, die mit log global konfiguriert sind.
Hier bei wird das Gerät (device = /dev/log), die Beschreibung (Facility = local0) und das Level (level = info) definiert.
Siehe auch: log
ssl-default-bind-options ssl-min-ver TLSv1.2
Diese Einstellung ist nur verfügbar, wenn die Unterstützung für OpenSSL in HAProxy verfügbar ist, was unter ArchLinux der Standard ist. Hier werden grundlegende ssl-Optionen gesetzt, die in allen bind-Parametern erzwungen werden und dadurch als Standard gelten.
Hier wird als minimale zulässiger SSL/TLS-Verschlüsselungs-Version TLSv1.2 erzwungen.
Siehe auch: ssl-default-bind-options
ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
Diese Einstellung ist nur verfügbar, wenn die Unterstützung für OpenSSL in HAProxy verfügbar ist, was unter ArchLinux der Standard ist. Hier werden die Standardalgorithmen, die die Liste der Verschlüsselungsalgorithmen („cipher suite“) beschreibt die während des SSL/TLS-Handshakes bis TLSv1.2 ausgehandelt werden, für alle bind-Parameter, die nicht explizit ihre eigenen definieren, als Standard gesetzt.
Siehe auch: ssl-default-bind-ciphers
Siehe auch nachfolgende externe Links:
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
Diese Einstellung ist nur verfügbar, wenn die Unterstützung für OpenSSL in HAProxy verfügbar ist, was unter ArchLinux der Standard ist und OpenSSL 1.1.1 oder höher zur Erstellung von HAProxy verwendet wurde. Hier werden die Standardalgorithmen, der die Liste der Verschlüsselungsalgorithmen („cipher suite“) beschreibt, die während des TLSv1.3 Handshakes für alle bind-Parameter die nicht explizit ihre eigenen definieren, als Standard gesetzt.
Siehe auch: ssl-default-bind-ciphersuites
Siehe auch nachfolgende externe Links:
stats socket /var/run/haproxy-admin.sock user root mode 600 level admin
stats socket /var/run/haproxy-operator.sock user haproxy mode 600 level operator
stats socket /var/run/haproxy-user.sock group wheel mode 660 level user
Bindet einen UNIX-Socket an einen <Pfad> oder eine TCPv4/v6-Adresse an eine/einen <Adresse:Port>. Verbindungen zu diesem Socket geben verschiedene statistische Ausgaben zurück und ermöglichen sogar die Anwendung von Befehle zur Änderung einiger Laufzeiteinstellungen.
Nachfolgend werden zusätzlich noch Zugriffsbeschränkungen gesetzt, wie z.B. die Besitz- undDateirechte des jeweiligen UNIX-Socket an einen <Pfad>.
Nachfolgend die Aufstellung:
| UNIX-Socket <Pfad> | lokale® Benutzer/Gruppe | Dateirechte | Berechtigungs-Level |
|---|---|---|---|
/var/run/haproxy-admin.sock | root (Benutzer) | 600 | admin |
/var/run/haproxy-opertator.sock | haproxy (Benutzer) | 600 | operator |
/var/run/haproxy-user.sock | wheel (Gruppe) | 660 | user |
Diese Einstellung wird nur bei den stats-Sockets verwendet, um die Art der Befehle einzuschränken, die von dem Socket ausgegeben werden können. Sie wird von anderen Sockets ignoriert. <level> kann einer der folgenden Werte sein:
Nachfolgende Liste erläutert die einzelnen Berechtigungs-Level:
| Level | Beschreibung |
|---|---|
admin | Sollte mit Vorsicht verwendet werden, da alles erlaubt ist (z. B. alle Zähler löschen). |
operator | ist die Standardstufe und eignet sich für die meisten Anwendungsfälle. Alle Daten können gelesen werden, und es sind nur nicht sensible Änderungen erlaubt (z. B. Löschen der Max-Zähler). |
user | ist die am wenigsten privilegierte Stufe. Nur nicht sensible Statistiken können gelesen werden und Änderungen sind nicht erlaubt. Dies kann auf Systemen sinnvoll sein, auf denen es nicht einfach ist, den Zugriff auf den Socket zu beschränken. |
stats maxconn 10
Standardmässig ist der stats-Socket auf 10 gleichzeitige Verbindungen beschränkt. Es ist möglich, diesen Wert entsprechend zu ändern.
stats timeout 10s
Der Standard-Zeitablauf für den stats-Socket ist auf 10 Sekunden eingestellt. Es ist möglich, diesen Wert entsprechend zu ändern. Der Wert muss in Millisekunden angegeben werden, oder es muss eine Zeiteinheit aus { us, ms, s, m, h, d } angehängt werden.
Beispiele: (Für die Benutzung eines stats-UNIX-Sockets)
Ausgabe der HAProxy-Version:
# echo "show version" | sudo -u root socat stdio unix-connect:/var/run/haproxy-admin.sock 2.7.1-3e4af0e
Auflistung aller möglichen Befehele:
# echo "help" | sudo -u root socat stdio unix-connect:/var/run/haproxy-admin.sock
HINWEIS - Der Befehl socat muss auf dem System verfügbar sein!
Sektion: defaults
Setzt alle Einstellungen auf die dokumentierten Standardeinstellungen zurück und gibt diese für die Verwendung durch die Sektionen frontend, backend und listen vor. Alle Sektionen übernehmen ihre Anfangseinstellungen immer aus der default-Sektion, und zwar standardmässig von der letzten Sektion, welche vor der neu erstellten Sektion erscheint.
mode http
Einstellen des Betriebsmodus oder des Protokolls der Instanz. Hier wird der Modus http für alle weiteren darunterliegenden Sektionen standardmässig vorgegeben.
Siehe auch: mode
timeout connect 5s
Legt die maximale Zeit fest, die gewartet werden soll, bis ein Verbindungsversuch zu einem Server erfolgreich ist.
Siehe auch: timeout connect
timeout client 10s
Legt die maximale Inaktivitätszeit auf der Client-Seite fest.
Siehe auch: timeout client
timeout server 10s
Legt die maximale Zeit fest, die anstehende Daten im Ausgabepuffer verbleiben.
Siehe auch: timeout server
option forwardfor
Einfügen des X-Forwarded-For-Headers in an Server gesendete Anfragen aktivieren.
Dies bewirkt unter anderem, das in den Log-Ausgaben des dahinter liegenden backend-Servers z.B. hier der Apache HTTPD Server die IP-Adresse des Clients erscheint und nicht die des HAProxy. Siehe auch nachfolgendes Beispiel:
192.168.0.99 - - [30/Dec/2022:15:12:54 +0100] "HEAD /favicon.ico HTTP/2.0" 200 1618 "https://srv030-apache.tachtler.net/server-status" "Mozilla/5.0 (X11; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0" TLSv1.3 TLS_AES_256_GCM_SHA384 1618 1600/1595 (100%)
Siehe auch: option forwardfor
option redispatch
Aktivieren oder Deaktivieren der Sitzungsumverteilung im Falle eines Verbindungsausfalls.
Wenn im HTTP-Modus ein mit einem cookie gekennzeichneter Server nicht mehr erreichbar ist, können die Clients nicht mehr auf den Dienst zugreifen, da sie das cookie nicht löschen können.
Der Parmeter erlaubt es dem Proxy, die cookie- oder konsistente Hash-basierte Persistenz aufzubrechen und sie auf einen funktionierenden Server umzuverteilen.
Siehe auch: option redispatch
option log-separate-errors
Änderung der Log-Ebene für nicht vollständig erfolgreiche Verbindungen. Manchmal ist es nicht einfach, in den Log-Schreibung nach Fehlern zu durchsuchen. Mit dieser Option kann der HAProxy dazu gebracht werden, die Ebene der Log-Einträge zu erhöhen und somit die potenziell interessante Informationen wie wie Fehler, Timeouts, Wiederholungen, Redispatches oder HTTP-Statuscodes 5xx einfacher auffindbar zu machen. Die Stufe ändert sich von info auf err.
Siehe auch: option log-separate-errors
option log-health-checks
Aktivieren oder Deaktivieren der Protokollierung von Statusaktualisierungen der Gesundheitsprüfungen (health checks). Standardmäßig werden fehlgeschlagene Gesundheitsprüfungen (health checks) protokolliert, wenn der Server „UP“ ist, und erfolgreiche Gesundheitsprüfungen, wenn der Server „DOWN“ ist, so dass die Menge an zusätzlichen Informationen begrenzt ist.
Wenn diese Option aktiviert ist, wird jede Änderung des Status der Gesundheitsprüfung (health checks) oder des Zustands des Servers protokolliert, so dass es möglich wird, zu überprüfen, dass ein Server vor dem Absturz, gelegentliche Prüfungen nicht bestanden hat, oder genauer zu überprüfen, wann dieser nicht mit einem gültigen HTTP-Status geantwortet hat, wann der Port anfing Verbindungen abzulehnen, und wann der Server überhaupt nicht mehr antwortete.
Siehe auch: option log-health-checks
option dontlognull
Aktivieren oder Deaktivieren der Protokollierung von leeren (Null)-Verbindungen. In den meisten Umgebungen gibt es Komponenten, die regelmäßig eine Verbindung zu verschiedenen Systemen herstellen, um sicherzustellen, dass sie noch am verfügbar/alktiv sind. Dies kann der Fall sein von einem Überwachungssystemen Checks ausgeführt werden. Standardmässig wird sogar eine einfache Port-Anfrage oder bei ein Scan ein Log-Eintrag erstellt. Damit diese Verbindungen die die Log-Schreibung zu sehr „verschmutzen“, ist es möglich, die Option dontlognull zu aktivieren, so dass eine Verbindung, über die keine Daten übertragen wurde, nicht protokolliert wird.
Siehe auch: option dontlognull
option dontlog-normal
Aktivieren oder Deaktivieren der Protokollierung von normalen, erfolgreichen Verbindungen. Es gibt Webseiten, die mit mehreren tausend Verbindungen pro Sekunde haben und für die die Protokollierung ein großes Problem darstellt. Einige von ihnen sind sogar gezwungen, diese abzuschalten und können Produktionsprobleme so nicht nachfollziehen (debuggen). Die Einstellung dieser Option gewährleistet, dass normale Verbindungen, d. h. solche, bei denen kein Fehler, keine Zeitüberschreitung, kein erneuter Versuch oder Redispatch aufgetreten sind, nicht protokolliert werden.
Siehe auch: option dontlog-normal
log global
Aktivieren der Protokollierung von Ereignissen und Datenverkehr pro Instanz.
Siehe auch: log global
Sektion: userlist stats-auth
Es ist möglich, den Zugriff auf die Bereiche frontend, backend und listen oder auf http-Statistiken zu kontrollieren, indem nur authentifizierte und autorisierte Benutzer zugelassen werden. Um dies zu tun, ist es erforderlich, mindestens eine Benutzerliste zu erstellen und Benutzer zu definieren.
userlist stats-auth
Es ist möglich, den Zugriff auf die Bereiche frontend, backend und listen oder auf http-Statistiken zu kontrollieren, indem nur authentifizierte und autorisierte Benutzer zugelassen werden. Um dies zu tun, ist es erforderlich, mindestens eine Benutzerliste zu erstellen und Benutzer zu definieren.
Es soll hier eine Benutzerliste mit der Bezeichnung stats-auth erstellt werden.
Siehe auch: userlists
group admin users admin
Fügt eine Gruppe <Gruppenname> zur aktuellen Benutzerliste hinzu. Es ist auch möglich
Benutzer zu dieser Gruppe hinzuzufügen, indem eine durch Komma getrennte Liste von Namen
gefolgt vom Schlüsselwort users erstellt wird.
Hier wird der <Gruppenname> admin verwendet. Der hier einzige Benutzer heisst ebenfalls admin.
Siehe auch: group
user admin insecure-password geheim
user admin password $6$SL1PdckVQG8NQMkI$dpV1BvlgcvJnAQJgnEVMRUapFqC41kyEdH/dTXrCIMjBEUklUZTrcLAEsA1Fx.tnNXmKvDBVvYx1of34kRt../
Fügt den Benutzer <Benutzername> zur aktuellen Benutzerliste hinzu. Es können sowohl sichere (verschlüsselte) als auch unsichere (unverschlüsselte) Passwörter verwendet werden. Verschlüsselte Passwörter werden mit der Funktion crypt(3) ausgewertet, so dass je nach den Fähigkeiten des Systems verschiedene Algorithmen unterstützt werden. Zum Beispiel unterstützen moderne Glibc basierte Linux-Systeme unterstützen beispielsweise MD5, SHA-256, SHA-512 und natürlich die klassische DES-basierte Methode zur Verschlüsselung von Passwörtern.
Zur Vereinfachung und zu Test-Zwecken wird huer dem Benutzer admin ein nicht verschlüsseltes Passwort zugewiesen:
Ein verschlüsseltes Passwort kann mit nachfolgendem Befehl erstellt werden:
# openssl passwd -6 -salt $(openssl rand -base64 16) Password: $6$SL1PdckVQG8NQMkI$dpV1BvlgcvJnAQJgnEVMRUapFqC41kyEdH/dTXrCIMjBEUklUZTrcLAEsA1Fx.tnNXmKvDBVvYx1of34kRt../
Siehe auch: user
Sektion: frontend http-in
Beschreibt eine Reihe von Sockets, die Client-Verbindungen annehmen.
option httplog
Aktivieren der Protokollierung von HTTP-Anfragen, Sitzungsstatus und Timern.
Siehe auch: option httplog
bind ipv4@:80,ipv6@:80 alpn h2,http/1.1
Definiert eine oder mehrere IP-Adressen und/oder Ports in einem Frontend, auf denen dieses Frontend lauscht.
Hier soll der HAProxy auf allen IPv4-Adressen auf Port 80 und auf allen alle IPv6-Adressen auf Port 80 lauschen und das Application-Layer Protocol Negotiation (ALPN) soll in der Reihenfolge das Hypertext Transfer Protocol (HTTP) in Version 2 zuerst und anschliessend in Version 1.1 angewendet werden.
HINWEIS - Die Reihenfolge der Angabe der Versionen des Hypertext Transfer Protocol (HTTP) ist hier entscheidend!
Siehe auch: bind
redirect scheme https code 301 if !{ ssl_fc }
Durchführung einer HTTP-Umleitung, wenn/falls eine Bedingung erfüllt ist.
Hier muss die Bedingung erfüllt sein, das es keine HTTPS-Verbindung ist. Anschliessend wird dem Client der HTTP-Statuscode 301 = Moved Permanently - Die angeforderte Ressource steht ab sofort unter der im „Location“-Header-Feld angegebenen Adresse bereit (auch Redirect genannt). Die alte Adresse ist nicht länger gültig. So dass hier eine Anfrage via HTTPS-Verbindung erneut vom Client gesendet werden muss, mit der URI aus dem „Location“-Header-Feld.
HINWEIS - Dies ist ein einfacher Redirect von HTTP auf HTTPS!
Siehe auch: redirect scheme
Sektion: frontend https-in
Beschreibt eine Reihe von Sockets, die Client-Verbindungen annehmen.
option httpslog
Aktivieren der Protokollierung von HTTPS-Anfragen, Sitzungsstatus und Timern.
Siehe auch: option httpslog
bind ipv4@:443,ipv6@:443 ssl crt haproxy.pem alpn h2,http/1.1
Definiert eine oder mehrere IP-Adressen und/oder Ports in einem Frontend, auf denen dieses Frontend lauscht.
Hier soll der HAProxy auf allen IPv4-Adressen auf Port 443 und auf allen alle IPv6-Adressen auf Port 443 lauschen. Weiterhin soll hier HTTPS als Protokoll genutz werden, was durch die Angabe des crt Zertifikats und dessen Pfad dorthin /etc/haproxy/haproxy.pem angegeben wird.Das Application-Layer Protocol Negotiation (ALPN) soll in der Reihenfolge das Hypertext Transfer Protocol (HTTP) in Version 2 zuerst und anschliessend in Version 1.1 angewendet werden.
Mit nachfolgendem Befehl kann die Zertifikatsdatei
/etc/haproxy/haproxy.pem
für den HAProxy erstellt werden:
# cat /path/to/fullchain.pem /path/to/privkey.pem > /etc/haproxy/haproxy.pem
WICHTIG - Die Angabe der Zertifikatsdatei kann nur ohne Pfad angegeben werden, wenn diese sich im gleichen Verzeichnis befindet, wie die Konfigurationsdatei haproxy.cfg und wenn der Paramater default-path config in der Sektion: global gesetzt wurde!
HINWEIS - Die Syntax der Zertifikatsdatei: cat certificate-full-chain certificate-private-key > combined-cert
HINWEIS - Die Reihenfolge der Angabe der Versionen des Hypertext Transfer Protocol (HTTP) ist hier entscheidend!
Siehe auch: bind
use_backend srv030-apache.tachtler.net if { hdr(host) -i srv030-apache.tachtler.net }
Wechsel zu einem bestimmten Backend, wenn/falls eine ACL-basierte Bedingung erfüllt ist.
Die Bedingung die hier erfüllt sein muss ist, dass die Angabe Host aus dem Hypertext Transfer Protocol (HTTP)-Header hier dem Wert srv030-apache.tachtler.net entsprechen muss, wobei bei der Prüfung die Gross- und Kleinschreibung ignoriert werden soll. Falls dies der Fall sein sollte, soll auf das backend - hier srv030-apache.tachtler.net, welches weiter unten in der Konfigurationsdatei konfiguriert ist, verzweigt werden.
Siehe auch: use_backend
HINWEIS - Da die Syntax immer die gleiche ist, wird hier nur ein Beispiel besprochen!
Sektion: backend stats
Beschreibt eine Reihe von Servern, mit denen sich der HAProxy verbindet um eingehende Verbindungen weiterzuleiten.
http-request set-path /haproxystats/%[path] if { hdr(host) -i lbproxy.tachtler.net }
Zugriffskontrolle für Layer 7-Anfragen
Die http-request-Anweisung definiert eine Reihe von Regeln, die für die Layer-7-Verarbeitung gelten. Die Regeln werden in der Reihenfolge ihrer Deklaration ausgewertet, wenn sie in einem frontend-, backend oder listen-Abschnitt erfüllt sind. Jeder Regel kann optional eine ACL-basierte Bedingung folgen. In diesem Fall wird die Regel nur ausgewertet, wenn die Bedingung erfüllt ist.
Siehe auch: http-request
stats enable
Aktiviert die Erstellung und Bereitstellung von Statistik-Berichten über eine Web-Oberfläche.
Siehe auch: stats enable
stats refresh 5s
Aktiviert die Aktualisierung der Statistik-Berichte. Hier im Intervall von 5 Sekunden
Siehe auch: stats refresh
stats show-desc HAProxy\ for\ tachtler.net
Aktiviert die Anzeige einer Beschreibung auf der Statistik-Berichte Seite. Hier mit der einfachen Beschreibung HAProxy\ for\ tachtler.net. (Die Angabe \ maskiert Leerzeichen)
Siehe auch: stats show-desc
stats show-legends
Aktiviert die Meldung zusätzlicher Informationen auf der Statistik-Berichte Seite.
Siehe auch: stats show-legends
stats show-node haproxy.tachtler.net
Aktiviert die Meldung eines „Hostnamens“ auf der Statistik-Berichte Seite.
Siehe auch: stats show-node
stats uri /haproxystats
Aktiviert und definiert das URI-Präfix für den Zugriff darauf. Dies ist besonders wichtig, da ohne diese Definition Konflikte mit anderen URI auftreten könnten.
HINWEIS - Vom Standard /haproxy?stats ist abzuraten, da aktuell über die Web-Oberfläche Probleme mit der Eingabe im Feld Scope und der Erweiterung der URI via HEAD enstehen.
Siehe auch: stats uri
acl AUTH http_auth(stats-auth)
Definiert eine ACL mit der Bezeichnung AUTH, welche dann Erfüllt ist, wenn eine Authentifizierung eines Benutzer der Gruppe http_auth(stats-auth) = stats-auth durchgeführt wird.
Siehe auch: ACL
acl AUTH_ADMIN http_auth_group(stats-auth) admin
Definiert eine ACL mit der Bezeichnung AUTH_ADMIN, welche dann Erfüllt ist, wenn der Benutzer admin aus der Gruppe http_auth_group(stats-auth) = stats-auth sich legitimiert hat.
Siehe auch: ACL
stats http-request auth realm HAProxy\ Statistics\ and\ Management unless AUTH
Zugangskontrolle für Statistiken. Fordert eine Authentifizierung vom Client an, mit der Beschreibung (realm) HAProxy\ Statistics\ and\ Management an, solange dies nicht bereits durchgeführt ist und bezieht sich auf die ACL mit der Bezeichnung AUTH. (Die Angabe \ maskiert Leerzeichen)
Siehe auch: stats http-request
stats admin if AUTH_ADMIN
Aktiviert die Statistik-Administrationsebene, wenn/falls eine Bedingung erfüllt ist. Die hier zu erfüllende Bedingung ist, das sich ein Benutzer, welcher sich in der Gruppe AUTH_ADMIN befindet erfolgreich z.B. durch den Client authentifiziert hat.
ACHTUNG - Die Administratoren-Ebene ermöglicht die Aktivierung/Deaktivierung von Servern über die Webschnittstelle. Standardmässig ist die Statistik-Berichte Seite aus Sicherheitsgründen schreibgeschützt!
Set state to MAINT- (Maintenance)Set state to DRAIN- (Austrocknen)Set state to READY- (Aktivierung)- uvm.
Siehe auch: stats admin
Sektion: backend [Server]
Beschreibt eine Reihe von Servern, mit denen sich der HAProxy verbindet um eingehende Verbindungen weiterzuleiten.
HINWEIS - Da die Syntax immer die gleiche ist, wird hier nur ein Beispiel, hier
backend srv030-apache.tachtler.net
besprochen!
option httpchk
Aktiviert das HTTP-Protokoll, um den Zustand des Servers zu überprüfen.
HINWEIS - Eine detailliertere Definition erfolgt über nachfolgende http-check Direktiven!
Siehe auch: option httpchk
http-check connect port 443 ssl sni apache-srv030.tachtler.net alpn h2,http/1.1
Öffnet eine neue Verbindung, um eine HTTP-Zustandsprüfung durchzuführen. Hier wird auf port 443 über die SSL-Version (HTTPS) des Hypertext Transfer Protocol (HTTP) und dem Namen für das entsprechende Zertifikat, welcher im Server Name Indication (SNI) enthalten sein muss, hier - apache-srv030.tachtler.net und über das Application-Layer Protocol Negotiation (ALPN) soll in der Reihenfolge das Hypertext Transfer Protocol (HTTP) in Version 2 zuerst und anschliessend in Version 1.1 angewendet werden, eine Überprüfung der Erreichbarkeit des backend-Servers durchgeführt werden.
Siehe auch: http-check connect
http-check send meth HEAD uri /favicon.ico ver HTTP/1.1 hdr User-Agent HAProxy hdr host apache-srv030.tachtler.net
Fügt eine mögliche Liste von Kopfzeilen und/oder einen Textkörper zu der Anfrage hinzu, die bei HTTP Gesundheitsprüfungen (health checks) gesendet werden. Hier soll die Methode HEAD zum Einsatz kommen und die URI - hier /favicon.ico überprüft werden, ob diese Datei in diesem Fall vom backend-Server via Hypertext Transfer Protocol (HTTP) in Version 1.1 abrufen werden kann, wenn der aus dem Hypertext Transfer Protocol (HTTP)-Header Feldern, hier dem Wert apache-srv030.tachtler.net entspricht.
HINWEIS - Die Angabe eines „User-Agent“ kann als Filter-Kriterium sinnvoll sein, wenn z.B. im backend-System z.B. Apache HTTP Server keine Log-Schreibung für die Überprüfungen (checks) durch den HAProxy erfolgen soll!
Siehe auch: http-check send
http-check expect status 200-399
http-check expect status 200-401
HTTP-Gesundheitsprüfungen (health-checks) können den Inhalt von Antworten oder bestimmte Statuscodes berücksichtigen. Falls der HTTP-Statuscode nicht im jeweils angegeben Bereich liegt, schlägt die HTTP-Gesundheitsprüfungen (health-checks) fehlt!
HINWEIS - Evtl. ist es erforderlich den HTTP-Statuscode 401 für Authentifizierungsanfragen mit zu berücksichtigen!
Siehe auch: http-check expect
cookie backend:srv030-apache.tachtler.net insert indirect nocache preserve secure maxidle 30m maxlife 3h
Aktiviert die Cookie-basierte Persistenz in einem bzw. auf ein backend.
HINWEIS - Hier ist es extrem wichtig, das der Name des cookie nicht mit anderen kollidiert!
Hier wird eine möglichst eindeutiger Name für den cookie - hier backend:srv030-apache.tachtler.net verwendet. Der Parameter insert besagt, das ein neuer cookie erstellt wird, falls kein cookie bereits existieren sollte. Dies wird auch nicht „gecached“, was der Parameter nocache bewirkt, damit nicht evtl. weitere Proxy dies tun. Der Parameter preserve ist extrem wichtig, das dieser unter anderem verhindert, das ein bestehender cookie überschrieben wird, was z.B. bei der Client Authentifizierung mittels z.B. „Basic-Auth“ nach sich ziehen würde. Es sollen nur secure cookie, falls nötig generiert werden. Die Lebensdauer für wartende Sitzungen (idle) und deren cookie beträgt hier 30m (30 Minuten) und die maximale Lebensdauer eines cookie beträgt hier - 3h (3 Stunde).
Siehe auch: cookie
server ipv4:apache 192.168.0.30:443 source ipv4@ ssl verify required ca-file /etc/ca-certificates/extracted/ca-bundle.trust.crt alpn h2,http/1.1 check inter 3s fall 3 rise 2 port 443 observe layer7 error-limit 50 on-error mark-down cookie ipv4:srv030-apache.tachtler.net maxconn 256
Deklarieren eines Servers in einem backend.
| Parameter | Beschreibung |
|---|---|
ipv4:apache | Name des Servers (auch in der Statistik-Bereich Anzeige) |
192.168.0.30:443 | IPv4-Adresse und Port Angabe, unter der der Server zu erreichen ist |
source ipv4@ | IPv4-Adresse des HAProxy von der aus der Server erreicht werden muss |
ssl verify required | WICHTIG - Erreichbarkeit nur via HTTPS mit Zertifikatsprüfung! |
ca-file /etc/ca-certificates/extracted/ca-bundle.trust.crt | Pfad im Betriebssystem zum Cert-Bundle |
alpn h2,http/1.1 | Application-Layer Protocol Negotiation (ALPN) in der Reihenfolge des Hypertext Transfer Protocol (HTTP) in Version 2 zuerst und anschliessend in Version 1.1 |
check inter 3s fall 3 rise 2 | Aktive Überprüfungsintervalle alle 3 Sekunden, bei 3 Fehlschlägen wird das backend auf „DOWN“ markiert, bei 2 darauf folgenden erfolgreichen Prüfungen wieder als „UP“ |
port 443 | Die Erreichbarkeit soll auf Port 443 erfolgen |
observe layer7 error-limit 50 on-error mark-down | Passive Überprüfung der Log-Schreibung, wenn 50 Fehlermeldungen in den LOG-Einträgen auftauchen wird das backend auf „DOWN“ gesetzt |
cookie ipv4:srv030-apache.tachtler.net | Name des Verbindungs cookie |
maxconn 256 | Maximale Anzahl der Verbindungen zum backend |
Siehe auch: server
server ipv6:apache fd00::dead:192:168:0:30:443 source ipv6@ ssl verify required ca-file /etc/ca-certificates/extracted/ca-bundle.trust.crt alpn h2,http/1.1 check inter 3s fall 3 rise 2 port 443 observe layer7 error-limit 50 on-error mark-down cookie ipv6:srv030-apache.tachtler.net maxconn 256
Deklarieren eines Servers in einem backend.
| Parameter | Beschreibung |
|---|---|
ipv6:apache | Name des Servers (auch in der Statistik-Bereich Anzeige) |
fd00::dead:192:168:0:30:443 | IPv6-Adresse und Port Angabe, unter der der Server zu erreichen ist |
source ipv6@ | IPv6-Adresse des HAProxy von der aus der Server erreicht werden muss |
ssl verify required | WICHTIG - Erreichbarkeit nur via HTTPS mit Zertifikatsprüfung! |
ca-file /etc/ca-certificates/extracted/ca-bundle.trust.crt | Pfad im Betriebssystem zum Cert-Bundle |
alpn h2,http/1.1 | Application-Layer Protocol Negotiation (ALPN) in der Reihenfolge des Hypertext Transfer Protocol (HTTP) in Version 2 zuerst und anschliessend in Version 1.1 |
check inter 3s fall 3 rise 2 | Aktive Überprüfungsintervalle alle 3 Sekunden, bei 3 Fehlschlägen wird das backend auf „DOWN“ markiert, bei 2 darauf folgenden erfolgreichen Prüfungen wieder als „UP“ |
port 443 | Die Erreichbarkeit soll auf Port 443 erfolgen |
observe layer7 error-limit 50 on-error mark-down | Passive Überprüfung der Log-Schreibung, wenn 50 Fehlermeldungen in den LOG-Einträgen auftauchen wird das backend auf „DOWN“ gesetzt |
cookie ipv4:srv030-apache.tachtler.net | Name des Verbindungs cookie |
maxconn 256 | Maximale Anzahl der Verbindungen zum backend |
Siehe auch: server
Basis-Konfiguration: Start
Bevor weitere Konfigurationsschritte erfolgen, sollte ein erster Start erfolgen, was mit nachfolgendem Befehl durchgeführt werden kann:
# systemctl start haproxy.service
HINWEIS - Es erfolgen keine weiteren Ausgaben, wenn der Start erfolgreich war !
Nachfolgende LOG-Einträge sollten beim Start des HAProxy zu sehen sein:
# journalctl -feu haproxy.service
Dec 30 22:40:26 vmtest systemd[1]: Starting HAProxy Load Balancer... Dec 30 22:40:26 vmtest haproxy[4324]: [NOTICE] (4324) : New worker (4214) forked Dec 30 22:40:26 vmtest systemd[1]: Started HAProxy Load Balancer. Dec 30 22:40:26 vmtest haproxy[4324]: [NOTICE] (4324) : Loading success. Dec 30 22:40:26 vmtest haproxy[4214]: [WARNING] (4214) : Health check for server srv030-apache.tachtler.net/ipv4:apache succeeded, reason: Layer7 check passed, code: 200, check duration: 8ms, status: 3/3 UP. Dec 30 22:40:26 vmtest haproxy[4214]: Health check for server srv030-apache.tachtler.net/ipv4:apache succeeded, reason: Layer7 check passed, code: 200, check duration: 8ms, status: 3/3 UP. Dec 30 22:40:26 vmtest haproxy[4214]: [WARNING] (4214) : Health check for server srv030-apache.tachtler.net/ipv6:apache succeeded, reason: Layer7 check passed, code: 200, check duration: 32ms, status: 3/3 UP. Dec 30 22:40:26 vmtest haproxy[4214]: Health check for server srv030-apache.tachtler.net/ipv6:apache succeeded, reason: Layer7 check passed, code: 200, check duration: 32ms, status: 3/3 UP. Dec 30 22:40:27 vmtest haproxy[4214]: [WARNING] (4214) : Health check for server phpldapadmin.tachtler.net/ipv4:apache succeeded, reason: Layer7 check passed, code: 401, check duration: 36ms, status: 3/3 UP. Dec 30 22:40:27 vmtest haproxy[4214]: Health check for server phpldapadmin.tachtler.net/ipv4:apache succeeded, reason: Layer7 check passed, code: 401, check duration: 36ms, status: 3/3 UP. Dec 30 22:40:27 vmtest haproxy[4214]: [WARNING] (4214) : Health check for server phpldapadmin.tachtler.net/ipv6:apache succeeded, reason: Layer7 check passed, code: 401, check duration: 30ms, status: 3/3 UP. Dec 30 22:40:27 vmtest haproxy[4214]: Health check for server phpldapadmin.tachtler.net/ipv6:apache succeeded, reason: Layer7 check passed, code: 401, check duration: 30ms, status: 3/3 UP. Dec 30 22:40:27 vmtest haproxy[4214]: [WARNING] (4214) : Health check for server srv040-apache.tachtler.net/ipv4:apache succeeded, reason: Layer7 check passed, code: 200, check duration: 7ms, status: 3/3 UP. Dec 30 22:40:27 vmtest haproxy[4214]: Health check for server srv040-apache.tachtler.net/ipv4:apache succeeded, reason: Layer7 check passed, code: 200, check duration: 7ms, status: 3/3 UP. Dec 30 22:40:28 vmtest haproxy[4214]: [WARNING] (4214) : Health check for server srv040-apache.tachtler.net/ipv6:apache succeeded, reason: Layer7 check passed, code: 200, check duration: 29ms, status: 3/3 UP. Dec 30 22:40:28 vmtest haproxy[4214]: Health check for server srv040-apache.tachtler.net/ipv6:apache succeeded, reason: Layer7 check passed, code: 200, check duration: 29ms, status: 3/3 UP. Dec 30 22:40:28 vmtest haproxy[4214]: [WARNING] (4214) : Health check for server repository.tachtler.net/ipv4:apache succeeded, reason: Layer7 check passed, code: 200, check duration: 14ms, status: 3/3 UP. Dec 30 22:40:28 vmtest haproxy[4214]: Health check for server repository.tachtler.net/ipv4:apache succeeded, reason: Layer7 check passed, code: 200, check duration: 14ms, status: 3/3 UP. Dec 30 22:40:28 vmtest haproxy[4214]: [WARNING] (4214) : Health check for server repository.tachtler.net/ipv6:apache succeeded, reason: Layer7 check passed, code: 200, check duration: 31ms, status: 3/3 UP. Dec 30 22:40:28 vmtest haproxy[4214]: Health check for server repository.tachtler.net/ipv6:apache succeeded, reason: Layer7 check passed, code: 200, check duration: 31ms, status: 3/3 UP.
Basis-Konfiguration: Tests
Wenn der Start des HAProxy erfolgreich durchgeführt wurde, kann die Abfrage mittels eines Clients erfolgen, wie im nachfolgenden Bild dargestellt:
Der Aufruf der Seite erfolgt hier in diesem Beispiel mittels:
| Parameter | Wert |
|---|---|
| Benutzer | admin |
| Passwort | geheim |
Ein Aufruf einer Apache HTTPD Sever - server-status-Seite über den HAProxy sollte wie gewohnt und wie folgt aussehen:
Nachfolgende LOG-Einträge sollten beim Aufruf des Apache HTTPD Sever zu sehen sein:
# less /var/log/httpd/srv030-apache.tachtler.net_access.log
192.168.0.99 - - [30/Dec/2022:22:46:45 +0100] "GET / HTTP/2.0" 301 256 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0" TLSv1.3 TLS_AES_256_GCM_SHA384 256 -/- (-%) 192.168.0.99 - - [30/Dec/2022:22:46:45 +0100] "GET /server-status HTTP/2.0" 401 887 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0" TLSv1.3 TLS_AES_256_GCM_SHA384 887 869/1568 (55%)
(Mit enthalten und dazwischen auch die health-checks des HAProxy):
fd00::dead:192:168:0:50 - - [30/Dec/2022:22:46:45 +0100] "HEAD /favicon.ico HTTP/2.0" 200 1595 "-" "-" TLSv1.3 TLS_AES_256_GCM_SHA384 1595 -/- (-%) 192.168.0.50 - - [30/Dec/2022:22:46:45 +0100] "HEAD /favicon.ico HTTP/2.0" 200 1595 "-" "-" TLSv1.3 TLS_AES_256_GCM_SHA384 1595 -/- (-%) fd00::dead:192:168:0:50 - - [30/Dec/2022:22:46:48 +0100] "HEAD /favicon.ico HTTP/2.0" 200 1595 "-" "-" TLSv1.3 TLS_AES_256_GCM_SHA384 1595 -/- (-%) 192.168.0.50 - - [30/Dec/2022:22:46:48 +0100] "HEAD /favicon.ico HTTP/2.0" 200 1595 "-" "-" TLSv1.3 TLS_AES_256_GCM_SHA384 1595 -/- (-%)
192.168.0.99 - klaus [30/Dec/2022:22:46:49 +0100] "GET /server-status HTTP/2.0" 200 2848 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0" TLSv1.3 TLS_AES_256_GCM_SHA384 2848 2830/34475 (8%) 192.168.0.99 - - [30/Dec/2022:22:46:49 +0100] "GET /favicon.ico HTTP/2.0" 200 1618 "https://srv030-apache.tachtler.net/server-status" "Mozilla/5.0 (X11; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0" TLSv1.3 TLS_AES_256_GCM_SHA384 1618 1600/1595 (100%)
Chroot-Konfiguration: /etc/haproxy/haproxy.cfg
Nachfolgende Konfigurationsschritte sollen eine chroot Konfiguration des HAProxy ermöglichen und erheben keinen Anspruch auf Vollständigkeit in Bezug auf die Möglichkeiten die der HAProxy bietet.
Bevor mit der Konfiguration des HAProxy weiter fortgefahren werden soll, sollte eine Sicherungskopie der bereits geänderten Konfigurationsdatei mit nachfolgendem Befehl durchgeführt werden:
# cp -a /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.before_chroot
Anschliessend kann die Konfigurationsdatei des HAProxy wie folgt ergänzt werden. Nur relevanter Ausschnitt:
global chroot /var/lib/haproxy user haproxy group haproxy
HINWEIS - Die vorhergehenden Konfigurationszeilen können irgendwo unter der Sektion: global hinzugefügt werden!
chroot /var/lib/haproxy
Hier wird zum Betrieb des HAProxy das aktuelle Verzeichnis nach /var/lib/haproxy gesetzt und führt dort ein chroot durch, bevor die Berechtigungen unter der der HAProxy läuft an den komnfigurierten Benutzer abgegeben werden. Dies erhöht das Sicherheitsniveau für den Fall, dass eine unbekannte Sicherheitslücke ausgenutzt werden würde, da es dem Angreifer sehr schwer gemacht würde, das System so zu kompromittieren. Dies funktioniert nur, wenn der Prozess mit Superuser-Rechten (root) gestartet wird. Es ist wichtig, sicherzustellen, dass /var/lib/haproxy sowohl leer als auch für keinen anderen Benutzer beschreibbar ausser dem an die die Rechte abgeben werden ist - hier nachfolgende haproxy.
Siehe auch: chroot
user haproxy
Verwendet die UID des Benutzernamens - hier haproxy aus der Konfigurationsdatei /etc/passwd.
Siehe auch: user
group haproxy
Verwendet die GID vom Gruppenname - hier haproxy aus der Konfigurationsdatei /etc/group.
Siehe auch: group
/var/lib/haproxy
Bevor jedoch ein Neustart erfolgen kann, muss das entsprechende Verzeichnis und eine Datei für das Gerät (device) auf das gemounted werden kann, welches als chroot-Verzeichnis verwendet werden soll, noch mit nachfolgenden Befehlen erstellt werden:
# mkdir -p /var/lib/haproxy/dev
# touch /var/lib/haproxy/dev/log
Des weiteren müssen noch die entsprechenden Besitz- und Dateirechte mit den nachfolgenden beiden Befehlen auch entsprechend gesetzt werden:
Besitzrechte
# chown -R root:root /var/lib/haproxy
Dateirechte
# chmod -R 755 /var/lib/haproxy
/etc/systemd/system/var-lib-haproxy-dev-log.mount
Sobald der HAProxy in einer chroot-Umgebung läuft, kann auf Bereiche ausserhalb der chroot-Umgebung nicht mehr zugegriffen werden.
Die betrifft insbesondere die LOG-Schreibung.
Deshalb ist es erforderlich das Gerät (device) /dev/log auch innerhalb der chroot-Umgebung zur Verfügung steht.
Die kann dadurch erreicht werden, das Gerät (device) /dev/log via systemd in die chroot-Umgebung gemounted wird.
Dazu wird mit nachfolgendem Befehl erst einmal ermittelt, wie die systemd-unit-Datei benannt werden muss:
# systemd-escape --suffix=mount --path /var/lib/haproxy/dev/log var-lib-haproxy-dev-log.mount
Anschliessend kann nun eine systemd-unit-Datei mit nachfolgendem Befehl und nachfolgendem Inhalt wie folgt erstellt werden:
# vim /etc/systemd/system/var-lib-haproxy-dev-log.mount
Mit nachfolgendem Inhalt:
[Unit] Requires=systemd-journald.service Description=/Expose Systemd Log for HAProxy [Mount] What=/dev/log Where=/var/lib/haproxy/dev/log Type=none Options=bind
Diese Änderungen müssen nun dem systemd-Dienst/Daemon noch mit nachfolgendem Befehl bekannt gemacht werden:
# systemctl daemon-reload
Als abschliessenden Konfigurationsschritt muss noch Sorge dafür getragen werden, das der mount der zuvor erstellen systemd-unit-Datei vor dem Start des HAProxy erfolgt, was innerhalb der systemd-unit-Start-Datei des HAProxy erfolgen kann. Die wird durch editieren der systemd-unit-Start-Datei des HAProxy mit nachfolgendem Befehl durchgeführt:
# systemctl edit haproxy.service
### Editing /etc/systemd/system/haproxy.service.d/override.conf ### Anything between here and the comment below will become the new contents of the file [Unit] Requires=var-lib-haproxy-dev-log.mount ### Lines below this comment will be discarded ### /usr/lib/systemd/system/haproxy.service # [Unit] # Description=HAProxy Load Balancer # After=network-online.target # Wants=network-online.target # # [Service] # EnvironmentFile=-/etc/default/haproxy # EnvironmentFile=-/etc/sysconfig/haproxy # Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid" "EXTRAOPTS=-S /run/haproxy-master.sock" # ExecStart=/usr/bin/haproxy -Ws -f $CONFIG -p $PIDFILE $EXTRAOPTS # ExecReload=/usr/bin/haproxy -Ws -f $CONFIG -c -q $EXTRAOPTS # ExecReload=/bin/kill -USR2 $MAINPID # KillMode=mixed # Restart=always # SuccessExitStatus=143 # Type=notify # # # The following lines leverage SystemD's sandboxing options to provide # # defense in depth protection at the expense of restricting some flexibility # # in your setup (e.g. placement of your configuration files) or possibly # # reduced performance. See systemd.service(5) and systemd.exec(5) for further # # information. # # # NoNewPrivileges=true # # ProtectHome=true # # If you want to use 'ProtectSystem=strict' you should whitelist the PIDFILE, # # any state files and any other files written using 'ReadWritePaths' or # # 'RuntimeDirectory'. # # ProtectSystem=true # # ProtectKernelTunables=true # # ProtectKernelModules=true # # ProtectControlGroups=true # # If your SystemD version supports them, you can add: @reboot, @swap, @sync # # SystemCallFilter=~@cpu-emulation @keyring @module @obsolete @raw-io # # [Install] # WantedBy=multi-user.target
Es wurden nachfolgende Zeilen hinzugefügt:
### Anything between here and the comment below will become the new contents of the file [Unit] Requires=var-lib-haproxy-dev-log.mount ### Lines below this comment will be discarded
Diese Änderungen müssen nun dem systemd-Dienst/Daemon ebenfalls noch mit nachfolgendem Befehl bekannt gemacht werden:
# systemctl daemon-reload
Abschliessen sollte nun nachfolgendes Verzeichnis mit nachfolgender Datei als Inhalt einstanden sein:
/etc/systemd/system/haproxy.service.d/override.conf
Chroot-Konfiguration: Neustart
Bevor weitere Konfigurationsschritte erfolgen, sollte ein Neustart erfolgen, was mit nachfolgendem Befehl durchgeführt werden kann:
# systemctl restart haproxy.service
HINWEIS - Es erfolgen keine weiteren Ausgaben, wenn der Start erfolgreich war !
Anschliessend kann mit nachfolgendem Befehl noch überprüft werden, ob der korrekt gestartet wurde:
# systemctl status haproxy.service
● haproxy.service - HAProxy Load Balancer
Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled; preset: disabled)
Drop-In: /etc/systemd/system/haproxy.service.d
└─override.conf
Active: active (running) since Mon 2023-01-02 16:37:19 CET; 1s ago
Main PID: 778 (haproxy)
Status: "Ready."
Tasks: 3 (limit: 2316)
Memory: 12.9M
CPU: 123ms
CGroup: /system.slice/haproxy.service
├─778 /usr/bin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -S /run/haproxy-master.sock
└─780 /usr/bin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -S /run/haproxy-master.sock
Jan 02 16:37:19 vmtest systemd[1]: Starting HAProxy Load Balancer...
Jan 02 16:37:19 vmtest haproxy[778]: [NOTICE] (778) : New worker (780) forked
Jan 02 16:37:19 vmtest haproxy[778]: [NOTICE] (778) : Loading success.
Jan 02 16:37:19 vmtest systemd[1]: Started HAProxy Load Balancer.
Jan 02 16:37:19 vmtest haproxy[780]: [WARNING] (780) : Health check for server vml030-apache.tachtler.net/ipv4:apach>
Jan 02 16:37:19 vmtest haproxy[780]: Health check for server vml030-apache.tachtler.net/ipv4:apache succeeded, reason>
Jan 02 16:37:19 vmtest haproxy[780]: [WARNING] (780) : Health check for server vml030-apache.tachtler.net/ipv6:apach>
Jan 02 16:37:19 vmtest haproxy[780]: Health check for server vml030-apache.tachtler.net/ipv6:apache succeeded, reason>
Jan 02 16:37:20 vmtest haproxy[780]: [WARNING] (780) : Health check for server phpldapadmin.tachtler.net/ipv4:apache>
Jan 02 16:37:20 vmtest haproxy[780]: Health check for server phpldapadmin.tachtler.net/ipv4:apache succeeded, reason:>
Zusätzlich kann überprüft werden, ob das Gerät (device) richtig gemounted wurde, was mit nachfolgendem Befehl durchgeführt werden kann:
# ls -l /var/lib/haproxy/dev/ total 0 srw-rw-rw- 1 root root 0 Jan 2 16:32 log
Maintenance-Konfiguration: /etc/haproxy/haproxy.cfg
Nachfolgende Konfigurationsschritte sollen eine Maintenance-Konfiguration (Wartungsseite) des HAProxy ermöglichen und erheben keinen Anspruch auf Vollständigkeit in Bezug auf die Möglichkeiten die der HAProxy bietet.
Durch die Maintenance-Konfiguration (Wartungsseite) wird eine individuelle Wartungsseite zur Anzeige gebracht, für den Fall, dass kein backend-Server mehr erreichbar sein sollte.
Bevor mit der Konfiguration des HAProxy weiter fortgefahren werden soll, sollte eine Sicherungskopie der bereits geänderten Konfigurationsdatei mit nachfolgendem Befehl durchgeführt werden:
# cp -a /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.before_maintenance
Anschliessend kann die Konfigurationsdatei des HAProxy wie folgt ergänzt werden. Nur relevanter Ausschnitt:
http-errors haerrors errorfile 503 /etc/haproxy/maintenance.htm
HINWEIS - Die vorhergehenden Konfigurationszeilen können als neue Sektion: mailers an irgendeiner Stelle innerhalb der Konfigurationsdatei /etc/haproxy/haproxy.cfg hinzugefügt werden!
In der Sektion: frontend - hier: (https-in) sind dann noch nachfolgende Ergänzungen hinzuzufügen:
errorfiles haerrors
http-errors haerrors
Erstellt eine neue http-Fehlergruppe mit dem Namen <Name> - hier haerrors. Es handelt sich um einen unabhängigen Abschnitt, auf den ein oder mehrere Proxys über seinen Namen verweisen können.
errorfile 503 /etc/haproxy/maintenance.htm
Zuordnung eines Dateiinhalts zu einem HTTP-Fehlercode.
errorfiles haerrors
Vwewendet ganz oder teilweise die Fehlerdateien, die im Abschnitt <Name> - hier haerrors http-errors Abschnitt definiert sind.
Maintenance-Konfiguration: /etc/haproxy/maintenance.htm
Nachfolgende Konfigurationsdatei soll neu erstellt werden und - hier - einen Einfachen Inhalt für eine Maintenance-Seite (Wartungsseite) im HTML-Format enthalten:
# vim /etc/haproxy/maintenance.htm
Der Inhalt könnte wie folgt aussehen:
HTTP/1.0 503 Service Unavailable Cache-Control: no-cache Connection: close Content-Type: text/html <!DOCTYPE html> <html lang="de"> <head> <meta charset="utf-8"> <meta http-equiv="x-ua-compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial scale=1.0, user-scalable=no"> <title data-i18n-key="app-title">Wartung</title> <style> html, body { padding: 0; margin: 0; width: 100%; height: 100%; } * {box-sizing: border-box;} body { text-align: center; padding: 0; background: #d6433b; color: #fff; font-family: Courier New; } h1 { font-size: 24px; font-weight: 100; text-align: center;} body { font-family: Courier New; font-weight: 100; font-size: 16px; color: #fff; text-align: center; display: -webkit-box; display: -ms-flexbox; display: flex; -webkit-box-pack: center; -ms-flex-pack: center; justify-content: center; -webkit-box-align: center; -ms-flex-align: center; align-items: center;} article { display: block; width: 700px; padding: 50px; margin: 0 auto; } b { color: #fff; font-weight: bold;} svg { width: 75px; margin-top: 1em; } </style> </head> <body> <article> <div class="container"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 202.24 202.24"><defs><style>.cls-1{fill:#fff;}</style></defs><title>Asset 3</title><g id="Layer_2" data-name="Layer 2"><g id="Capa_1" data-name="Capa 1"><path class="cls-1" d="M101.12,0A101.12,101.12,0,1,0,202.24,101.12,101.12,101.12,0,0,0,101.12,0ZM159,148.76H43.28a11.57,11.57,0,0,1-10-17.34L91.09,31.16a11.57,11.57,0,0,1,20.06,0L169,131.43a11.57,11.57,0,0,1-10,17.34Z"/><path class="cls-1" d="M101.12,36.93h0L43.27,137.21H159L101.13,36.94Zm0,88.7a7.71,7.71,0,1,1,7.71-7.71A7.71,7.71,0,0,1,101.12,125.63Zm7.71-50.13a7.56,7.56,0,0,1-.11,1.3l-3.8,22.49a3.86,3.86,0,0,1-7.61,0l-3.8-22.49a8,8,0,0,1-.11-1.3,7.71,7.71,0,1,1,15.43,0Z"/></g></g></svg> <h1 data-i18n-key="app-head">Wir sind bald wieder da!</h1> <p data-i18n-key="app-text">Bitte entschuldigen Sie die Unannehmlichkeiten.<br>Wir führen <b><u>im Moment Wartungsarbeiten</u></b> durch.<br>Wir sind in Kürze wieder für Sie da!</p> </div> </article> <script> // The locale our app first shows const defaultLocale = "de"; const supportedLocales = ["de", "en"]; // Check if locale ist supported function isSupported(locale) { return supportedLocales.indexOf(locale) > -1; } // Retrieve the first locale we support from the given // array, or return our default locale function supportedOrDefault(locales) { return locales.find(isSupported) || defaultLocale; } // Detect browser locale function browserLocales(languageCodeOnly = false) { return navigator.languages.map((locale) => languageCodeOnly ? locale.split("-")[0] : locale, ); } // Translations const translations = { // German translations "de": { "app-title": "Wartung", "app-head": "Wir sind bald wieder da!", "app-text": "Bitte entschuldigen Sie die Unannehmlichkeiten.</br>Wir führen <b><u>im Moment Wartungsarbeiten</u></b> durch.</br>Wir sind in Kürze wieder für Sie da!", }, // English translations "en": { "app-title": "Maintenance", "app-head": "We’ll be back soon!", "app-text": "Sorry for the inconvenience.</br>We’re performing <b><u>maintenance at the moment.</u></b></br>We’ll be back up shortly!", }, }; // When the page content is ready document.addEventListener("DOMContentLoaded", () => { document // Find all elements that have the key attribute .querySelectorAll("[data-i18n-key]") .forEach(translateElement); }); // Replace the inner text of the given HTML element // with the translation in the active locale, // corresponding to the element's data-i18n-key function translateElement(element) { const key = element.getAttribute("data-i18n-key"); const initialLocale = supportedOrDefault(browserLocales(true)); const translation = translations[initialLocale][key]; element.innerHTML = translation; } </script> </body> </html>
Maintenance-Konfiguration: Neustart
Bevor weitere Konfigurationsschritte erfolgen, sollte ein Neustart erfolgen, was mit nachfolgendem Befehl durchgeführt werden kann:
# systemctl restart haproxy.service
HINWEIS - Es erfolgen keine weiteren Ausgaben, wenn der Start erfolgreich war !
Maintenance-Konfiguration: Test
Wenn der Start des HAProxy erfolgreich durchgeführt wurde, kann die Abfrage mittels eines Clients erfolgen, wie im nachfolgenden Bild dargestellt:
Cache-Konfiguration: /etc/haproxy/haproxy.cfg
Nachfolgende Konfigurationsschritte sollen Cache im RAM einrichten.
HAProxy bietet einen Cache an, der für die Zwischenspeicherung von kleinen Objekten z.B. (favicon.ico, CSS uva.) konzipiert wurde. Es handelt sich um einen minimalistischen, wartungsarmen Cache, der im RAM läuft.
Der Cache basiert auf einem von allen „Threads“ gemeinsam genutzten Speicherbereich, der in 1 KB (KiloByte)-Blöcke unterteilt ist.
Wenn ein Objekt nicht mehr gebraucht wird, kann es gelöscht werden, um ein neues Objekt zu speichern, unabhängig von seinem Verfallsdatum. Die ältesten Objekte werden zuerst gelöscht, wenn versucht wird, ein neues Objekt zuzuweisen.
Der Cache verwendet einen „Hash“ aus dem „Host-Header“ und dem „URI“ als Schlüssel.
Wenn ein Objekt aus dem Cache geliefert wird, wird der Servername im Protokoll durch „<CACHE>“ ersetzt.
Wenn konfiguriert, werden Objekte im RAM gecached und in der Sektion cache werden dazu die Basis-Einstellungen hinterlegt.
Bevor mit der Konfiguration des HAProxy weiter fortgefahren werden soll, sollte eine Sicherungskopie der bereits geänderten Konfigurationsdatei mit nachfolgendem Befehl durchgeführt werden:
# cp -a /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.before_cache
Anschliessend kann die Konfigurationsdatei des HAProxy wie folgt ergänzt werden. Nur relevanter Ausschnitt:
cache hacache total-max-size 256 max-object-size 1048576 max-age 60 process-vary off max-secondary-entries 10
HINWEIS - Die vorhergehenden Konfigurationszeilen können als neue Sektion: cache an irgendeiner Stelle innerhalb der Konfigurationsdatei /etc/haproxy/haproxy.cfg hinzugefügt werden!
In einer Sektion: backend oder listen sind dann noch nachfolgende Ergänzungen hinzuzufügen:
http-request cache-use hacache http-response cache-store hacache
cache hacache
Deklaration des Cache-Abschnitt, in dem ein gemeinsamer Cache-Speicher mit dem Namen <Name> - hier hacache erstellt wird.
total-max-size 256
Die Grösse des Caches im RAM in Megabyte. Diese Grösse wird in Blöcke von 1 KB (KiloByte) aufgeteilt, die von den Cache-Einträgen verwendet werden. Der Höchstwert ist 4095.
max-object-size 1048576
Die maximale Grösse der zwischen zu speichern den Objekte in Bytes. Diese darf nicht grösser sein als die Hälfte von total-max-size. Ist diese nicht festgelegt, entspricht sie einem 256stel der Cache-Grösse. Alle Objekte, deren Grösse grösser als max-object-size ist, werden nicht zwischengespeichert.
max-age 60
Die maximale Verfallsdauer. Die Verfallsdauer wird als der niedrigste Wert zwischen der Direktive „s-maxage“ oder „max-age“ (in dieser Reihenfolge) im Antwort-Header „Cache-Control“ und diesem Wert festgelegt. Der Standardwert ist 60 Sekunden, was bedeutet, dass ein Objekt standardmässig nicht länger als 60 Sekunden zwischengespeichert werden kann.
process-vary off
Die Verarbeitung des „Vary-Headers“ [on|off]. Wenn diese Option deaktiviert ist, wird eine Antwort, die einen solchen Header enthält, niemals zwischengespeichert. Wenn diese Option aktiviert ist, muss ein vorläufiger „Hash“ für eine Untergruppe von Anfrage-Headern für alle eingehenden Anfragen berechnet werden (was mit Rechenzeitkosten verbunden sein kann), der zur Erstellung eines sekundären Schlüssels für eine bestimmte Anfrage verwendet wird (siehe RFC 7234#4.1). Der Standardwert ist off (deaktiviert).
max-secondary-entries 10
Die maximale Anzahl von gleichzeitigen sekundären Einträgen mit demselben primären Schlüssel im Cache. Dazu muss die „vary“-Unterstützung aktiviert sein. Der Standardwert ist 10 und sollte als strenge positive ganz Zahl übergeben werden.
http-request cache-use hacache
Versucht, ein zwischengespeichertes Objekt aus dem Cache <Name> - hier hacache zu liefern. Diese Direktive ist auch zwingend erforderlich, um den Cache zu speichern, da sie den Cache-„Hash“ berechnet. Wenn eine Bedingung sowohl für die Speicherung als auch für die Auslieferung verwenden soll, sollte diese nach dieser Anweisung gesetzte werden.
http-response cache-store hacache
Speichern einer http-Antwort im Cache. Die Speicherung der Antwort-„Header“ erfolgt in diesem Schritt, was bedeutet, dass andere http-Antwort-Aktionen verwenden werden können, um „Header“ vor oder nach der Speicherung der Antwort zu ändern. Diese Aktion ist für die Einrichtung des Cache-Speicherfilters verantwortlich.
Cache-Konfiguration: Limitationen
In nachfolgenden Fällen speichert der Cache keine Objekte und liefert diese auch nicht aus:
- Wenn die Antwort nicht einen HTTP-Statuscode von
200hat - Wenn die Antwort einen „Vary-Header“ enthält und entweder die Option „process-vary“ deaktiviert ist oder ein derzeit nicht verwalteter Header im „Vary“-Wert angegeben ist (nur „accept encoding“ und „referer“ werden derzeit verwaltet)
- Wenn die „Content-Length“ (Inhalts-Länge) + die „Header“-Größe grösser als
max-object-sizist - Wenn die Antwort nicht Cache-fähig ist
- Wenn die Antwort keine explizite Verfallszeit („s-maxage“ oder „max-age“ „Cache-Control“-Direktiven oder „Expires-Header“) oder einen „Validator“ („ETag“ oder „Last-Modified-Header“) hat
- Wenn die Option „process-vary“ aktiviert ist und es bereits
max-secondary-entries-Einträge mit demselben Primärschlüssel wie die aktuelle Antwort gibt - Wenn die Option „process-vary“ aktiviert ist und die Antwort eine unbekannte Kodierung aufweist (nicht in Hypertext Transfer Protocol (HTTP) Parameter erwähnt) während der Variation auf den „accept encoding“ Client-Header zeigt
- Wenn die Anfrage kein
GETist - Wenn die HTTP-Version der Anfrage kleiner als 1.1 ist
- Wenn die Anfrage einen „Authorization-Header“ enthält
Cache-Konfiguration: Neustart
Bevor weitere Konfigurationsschritte erfolgen, sollte ein Neustart erfolgen, was mit nachfolgendem Befehl durchgeführt werden kann:
# systemctl restart haproxy.service
HINWEIS - Es erfolgen keine weiteren Ausgaben, wenn der Start erfolgreich war !
Zusätzlich kann überprüft werden, ob der Cache-Speicher im RAM aktiviert wurde, was mit nachfolgendem Befehl durchgeführt werden kann:
# echo "show cache" | sudo -u root socat stdio unix-connect:/var/run/haproxy-admin.sock 0x7f57a73ff03a: hacache (shctx:0x7f57a73ff000, available blocks:262144)
E-Mail-Konfiguration: /etc/haproxy/haproxy.cfg
Nachfolgende Konfigurationsschritte sollen eine E-Mail Benachrichtigungs-Konfiguration des HAProxy ermöglichen und erheben keinen Anspruch auf Vollständigkeit in Bezug auf die Möglichkeiten die der HAProxy bietet.
Es ist möglich, E-Mail-Benachrichtigungen zu senden, wenn sich der Status von Servern ändert.
Wenn konfiguriert, werden E-Mail-Benachrichtigungen an jeden in der Sektion mailers konfigurierten E-Mail-Server gesendet. E-Mails werden über SMTP an die mailers gesendet.
Bevor mit der Konfiguration des HAProxy weiter fortgefahren werden soll, sollte eine Sicherungskopie der bereits geänderten Konfigurationsdatei mit nachfolgendem Befehl durchgeführt werden:
# cp -a /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.before_mailers
Anschließend kann die Konfigurationsdatei des HAProxy wie folgt ergänzt werden. Nur relevanter Ausschnitt:
mailers hamailers
timeout mail 10s
mailer mxlocal 192.168.0.50:25
HINWEIS - Die vorhergehenden Konfigurationszeilen können als neue Sektion: mailers an irgendeiner Stelle innerhalb der Konfigurationsdatei /etc/haproxy/haproxy.cfg hinzugefügt werden!
In einer Sektion: backend oder listen sind dann noch nachfolgende Ergänzungen hinzuzufügen:
email-alert mailers hamailers email-alert myhostname haproxy.tachtler.net email-alert from haproxyalert@tachtler.net email-alert to haproxy@tachtler.net email-alert level info
timeout mail 10s
Legt die Zeit fest, die zur Verfügung steht, um eine E-Mail/Verbindung aufzubauen und an den E-Mail-Server zu senden. Falls diese Option nicht definiert sein sollte, ist der Standardwert 10 Sekunden. Damit beim ersten TCP-Handshake mindestens zwei „SYN-ACK-Pakete“ gesendet werden können, wird empfohlen, diesen Wert über 4 Sekunden zu setzen.
mailer mxlocal 192.168.0.50:25
Definiert einen „Mailer“ innerhalb eines mailers-Abschnitts. Die Definition ist hier als ersten Parameter einen beliebigen Namen, hier mxlocal gefolgt von einer IP-Adresse, hier IPv4 und 192.168.0.50 und einem Port, hier 25.
HINWEIS - Es sind mehrere Einträge möglich, welche jedoch alle eine unterschiedlichen Namen benötigen z.B. mx1, mx2 usw.
HINWEIS - Die Verwendung eines submission Port, wie in der originalen Dokumentation ist nicht sinnvoll, da aktuell keine Authentifizierungsparameter wie Benutzername und Passwort übergeben werden können!
email-alert mailers hamailers
Deklarieren die „Mailer“, die beim Versand von E-Mail-Benachrichtigungen verwendet werden sollen.
email-alert myhostname haproxy.tachtler.net
Die Bezeichnung des Hostnamen, die bei der Kommunikation mit „Mailern“ verwendet werden soll.
HINWEIS - Dies sollte der DNS-Forward-Auflösung des Systems entsprechen
email-alert from haproxyalert@tachtler.net
Die Absender-E-Mail-Adresse, die sowohl im „ENVELOP“ als auch in der Kopfzeile der E-Mail-Warnungen verwendet werden soll. Dies ist die Absender E-Mail-Adresse, von der aus die E-Mail-Warnungen gesendet werden.
email-alert to haproxy@tachtler.net
Die Empfängeradresse im „ENVELOP“ als auch die Empfänger E-Mail-Adresse in der Kopfzeile der E-Mail-Benachrichtigungen. Dies ist die Empfänger E-Mail-Adresse, an die E-Mail-Warnungen gesendet werden.
email-alert level info
Gibt die Protokollierungsstufe von Nachrichten an, für die E-Mail-Benachrichtigungen gesendet werden sollen. Dies dient als Filter für den Versand von E-Mail-Warnungen.
Eine der 8 Syslog-Ebenen: emerg, alert, crit, err, warning, notice, info und debug
Die obigen „Syslog-Levels“ sind vom niedrigsten zum höchsten geordnet. Standardmäßig ist der Level alert gesetzt, falls der Parameter nicht gesetzte wird.
Mailers-Konfiguration: Neustart
Bevor weitere Konfigurationsschritte erfolgen, sollte ein Neustart erfolgen, was mit nachfolgendem Befehl durchgeführt werden kann:
# systemctl restart haproxy.service
HINWEIS - Es erfolgen keine weiteren Ausgaben, wenn der Start erfolgreich war !
Mailers-Konfiguration: Test
Nachfolgend E-Mail-Benachrichtigungen werden durch den HAProxy versendet, wenn z.B. einer der backend-Systeme, hier ein Apache HTTP Webservers ausfällt und nach einer gewissen Ausfallzeit wieder erreichbar ist.
Nachfolgende die E-Mail-Benachrichtigungen:
HINWEIS - Uhrzeit: 17:40:50 Uhr bis 17:43:11 Uhr
ACHTUNG - 56 E-Mail-Benachrichtigungen = (2:21 Min) = (ca. alle 3 Sek. = Check-Intervall, eine E-Mail-Benachrichtigung) !
(Nur relevanter Ausschnitt)
Erstes Auftreten, Server Problem festgestellt
Subject: [HAProxy Alert] Health check for server repository.tachtler.net/ipv4:apache failed, reason: Layer4 connection problem, check duration: 3002ms, status: 2/3 UP Health check for server repository.tachtler.net/ipv6:apache failed, reason: Layer4 connection problem, check duration: 3002ms, status: 2/3 UP
Server „DOWN“ ermittelt
Subject: [HAProxy Alert] Server repository.tachtler.net/ipv4:apache is DOWN. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue Server repository.tachtler.net/ipv6:apache is DOWN. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue
Server erholt sich wieder, festgestellt
Subject: [HAProxy Alert] Health check for server repository.tachtler.net/ipv4:apache succeeded, reason: Layer7 check passed, code: 200, check duration: 2123ms, status: 1/2 DOWN Health check for server repository.tachtler.net/ipv4:apache succeeded, reason: Layer7 check passed, code: 200, check duration: 2123ms, status: 1/2 DOWN
Server „UP“ ermittelt
Subject: [HAProxy Alert] Health check for server repository.tachtler.net/ipv4:apache succeeded, reason: Layer7 check passed, code: 200, check duration: 8ms, status: 3/3 UP Health check for server repository.tachtler.net/ipv4:apache succeeded, reason: Layer7 check passed, code: 200, check duration: 8ms, status: 3/3 UP