The purpose of this article is to demonstrate how a modern version of HAProxy 2 long term support (LTS) can be installed on a CentOS 7.9 server. Although HAProxy RPMs are available under EPEL with CentOS, they lag behind the current LTS versions available (the major version is 2.6 as of this writing - information on HAProxy releases and LTS schedule can be found in the table published at the HAProxy website).
Finding information online for this procedure can be difficult and, unfortunately, much of it can be incomplete re: steps related to logging and proper integration with systemd. We will cover those items as well. Installation of CentOS 7.9 Server and creating a full working HAProxy configuration will be kept out of scope, however. The focus will be on building and installing necessary binaries, setting up logging with rsyslog, and confirming basic operation.
This work is derived from the following resources, although we cannot guarantee the referenced links will always be available. All the more reason to capture the process here.
How to install the latest version of haproxy on centos 7
Regarding CentOS 7.9 and OpenSSL
The reader should be aware that the latest version of OpenSSL available in the CentOS 7.9 repo is “OpenSSL 1.0.2k-fips”:
[root@ebony2 haproxy-2.6.6]# openssl version OpenSSL 1.0.2k-fips 26 Jan 2017 [root@ebony2 haproxy-2.6.6]#
Per the vulnerabilities page on the OpenSSL web site (found here):
“Note: All OpenSSL versions before 1.1.1 are out of support and no longer receiving updates. Extended support is available for 1.0.2 from OpenSSL Software Services for premium support customers.”
If you do plan to use CentOS 7.9 in production with HAProxy encapsulating traffic with SSL/TLS, you will need to bear this in mind. Upgrading OpenSSL on CentOS 7.9 to a more current release is out of scope for this article and is left as an exercise to the reader.
Installation Procedure
Prepare the Build Environment and Download HAProxy
Log into your CentOS 7.9 Server as ‘root’ user and perform the following…
Install the packages needed to compile HAProxy from source (note the package ‘systemd-devel’, this is needed for systemd integration for HAProxy when it’s built):
yum -y install gcc-c++ openssl-devel pcre-static pcre-devel systemd-devel
Next, download the HAProxy version that you want to build (versions available can be found here, in our example we will build version 2.6.6):
wget https://www.haproxy.org/download/2.6/src/haproxy-2.6.6.tar.gz
Unpack the file and change directory into where it was unpacked:
tar xvfz haproxy-2.6.6.tar.gz cd haproxy-2.6.6/
Once in the main source directory, build HAProxy using the build flags outlined below (note the build directive for USE_SYSTEMD=1, this is needed for systemd integration). Note also that we add the flag USE_PROMEX=1 to enable the built-in Prometheus exporter for HAProxy:
make TARGET=linux-glibc USE_PCRE=1 USE_PROMEX=1 USE_OPENSSL=1 USE_ZLIB=1 USE_CRYPT_H=1 USE_LIBCRYPT=1 USE_SYSTEMD=1
Create the directory /etc/haproxy in preparation for performing install of the binaries and as a home for the haproxy.cfg we will need to create, then perform the installation:
mkdir /etc/haproxy make install
After that step, you should see haproxy installed in /usr/local/sbin on the server, you can then run a quick version check to make sure it can execute:
[root@haproxy-test ~]# which haproxy /usr/local/sbin/haproxy [root@haproxy-test ~]# haproxy -v HAProxy version 2.6.6-274d1a4 2022/09/22 - https://haproxy.org/ Status: long-term supported branch - will stop receiving fixes around Q2 2027. Known bugs: http://www.haproxy.org/bugs/bugs-2.6.6.html Running on: Linux 3.10.0-1160.83.1.el7.x86_64 #1 SMP Wed Jan 25 16:41:43 UTC 2023 x86_64 [root@haproxy-test ~]#
Now that we have the necessary binaries installed, we can move on to configuration. There are two things that need to be set up next:
The HAProxy systemd service file
The haproxy.cfg file
This is done as follows, first for the systemd service file:
cat > /usr/lib/systemd/system/haproxy.service << 'EOL'
[Unit]
Description=HAProxy Load Balancer
After=syslog.target network.target
[Service]
Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid"
ExecStartPre=/usr/local/sbin/haproxy -f $CONFIG -c -q
ExecStart=/usr/local/sbin/haproxy -Ws -f $CONFIG -p $PIDFILE
ExecReload=/usr/local/sbin/haproxy -f $CONFIG -c -q
ExecReload=/bin/kill -USR2 $MAINPID
KillMode=mixed
Restart=always
SuccessExitStatus=143
Type=notify
[Install]
WantedBy=multi-user.target
EOL
Next, we use a similar technique to create a very basic haproxy.cfg file for testing. Note that we are overriding the default logging approach here which uses a Unix socket target. Our goal is to drop in the necessary hooks to allow us to send logs to a remote logging server. For testing purposes to that end, we will send all HAProxy log traffic over default UDP port 514 to an rsyslog server running on the same host, using logging facility '1' (this is done with the line “log 127.0.0.1 local1").
NOTE: this is not a fully functional haproxy.cfg example, this is only a stub to test logging!
cat > /etc/haproxy/haproxy.cfg << 'EOL'
global
log 127.0.0.1 local1
daemon
# Tune up maxx conns
maxconn 2048
tune.ssl.default-dh-param 2048
defaults
log global
option dontlognull
timeout connect 50000
timeout client 50000
timeout server 50000
listen ListenName
bind *:80
mode tcp
server YourServer 127.0.0.1:80
EOL
Now, with these two items in place, we need to perform some changes to the /etc/rsyslog.conf file to allow it to act in the role of “remote log server”. We also want to avoid having these log messages sent to other log file targets on the system (such as the /var/log/messages file). We make the following changes to rsyslog.conf to accommodate this.
Uncomment the lines in /etc/rsyslog.conf for handling remote UDP log traffic:
# Provides UDP syslog reception $ModLoad imudp $UDPServerRun 514
Next, make adjustments to the “RULES” section in rsyslog.conf for the log facility directives related to /var/log/messages:
# Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none;local0.none;local1.none;local2.none;local3.none;local4.none;local5.none;local6.none /var/log/messages
Finally, you will need to add a facility definition for local1 so that all messages using that facility (which should be dedicated for HAProxy) are logged in /var/log/haproxy.log:
# Let's send haproxy logs here local1.* /var/log/haproxy.log
Once those changes are made for rsyslog, you will need to restart it for them to take hold, you can check its status after issuing the restart also in case there were any errors in the above changes:
systemctl restart rsyslog systemctl status rsyslog -l
We should now be ready to start HAProxy as follows, along with checking its status in case there are any errors on startup. It helps to have an empty log file ready in /var/log/haproxy.log so we include that step here as well:
touch /var/log/haproxy.log systemctl start haproxy systemctl status haproxy -l
If all is working properly, you should see the following output in /var/log/messages:
Mar 1 13:29:04 haproxy-test systemd: Starting HAProxy Load Balancer... Mar 1 13:29:04 haproxy-test haproxy: [NOTICE] (23510) : New worker (23514) forked Mar 1 13:29:04 haproxy-test haproxy: [NOTICE] (23510) : Loading success. Mar 1 13:29:04 haproxy-test systemd: Started HAProxy Load Balancer.
Now, let’s generate a smoke test of client traffic against the system to make sure session traffic is being properly logged in /var/log/haproxy.log. This can be done with the simple curl command below, run it for a couple of seconds then hit ‘^C’ to exit out:
curl -ifsS 'http://127.0.0.1:80'
After breaking out of the above curl command, you should see session log entries present in /var/log/haproxy.log per the example below (Note again, this isn’t representative of logging production HTTP/HTTPS traffic, it’s simply a test to see if communication to the remote log server works - your eventual log entries will be different in practice when you set things up to perform real load balancing work):
[root@haproxy-test log]# pwd /var/log [root@haproxy-test log]# tail haproxy.log Mar 1 13:33:28 localhost haproxy[23514]: Connect from 127.0.0.1:48342 to 127.0.0.1:80 (ListenName/TCP) Mar 1 13:33:28 localhost haproxy[23514]: Connect from 127.0.0.1:48344 to 127.0.0.1:80 (ListenName/TCP) Mar 1 13:33:28 localhost haproxy[23514]: Connect from 127.0.0.1:48346 to 127.0.0.1:80 (ListenName/TCP) Mar 1 13:33:28 localhost haproxy[23514]: Connect from 127.0.0.1:48348 to 127.0.0.1:80 (ListenName/TCP) Mar 1 13:33:28 localhost haproxy[23514]: Connect from 127.0.0.1:48350 to 127.0.0.1:80 (ListenName/TCP) Mar 1 13:33:28 localhost haproxy[23514]: Connect from 127.0.0.1:48352 to 127.0.0.1:80 (ListenName/TCP) Mar 1 13:33:28 localhost haproxy[23514]: Connect from 127.0.0.1:48354 to 127.0.0.1:80 (ListenName/TCP) Mar 1 13:33:28 localhost haproxy[23514]: Connect from 127.0.0.1:48356 to 127.0.0.1:80 (ListenName/TCP) Mar 1 13:33:28 localhost haproxy[23514]: Connect from 127.0.0.1:48358 to 127.0.0.1:80 (ListenName/TCP) Mar 1 13:33:28 localhost haproxy[23514]: Connect from 127.0.0.1:48360 to 127.0.0.1:80 (ListenName/TCP) [root@haproxy-test log]#
If you see this, then you have a working HAProxy 2.6 LTS in place that’s set up for remote logging. Congratulations!
From here, we recommend that you review our other articles related to HAProxy. One article in particular can be found here, as the next step usually involves setting up TLS testing with a Swarm Gateway farm in place:
Configuring haproxy SSL offloading with a Self Signed Certificate on Content Gateway
Additional Notes
Sometimes, it’s necessary to make adjustments for default resource limits for HAProxy. This usually involves increasing the open file limit for the HAProxy process. Since we’re fully integrated with systemd in the above example, we can take advantage of that to create a resource limits file for the HAProxy process.
First, you will need to create a service directory for the HAProxy systemd service:
mkdir -p /etc/systemd/system/haproxy.service.d
Now, we want to create a file named ‘limits.conf’ in that directory, then edit it to increase the file limit (you can use text editor of choice, here we use ‘vi’):
vi /etc/systemd/system/haproxy.service.d/limits.conf
Place the following setting scope and associated setting in that file:
[Service] LimitNOFILE=500000
Once that is done, you will need to direct systemd to reload daemon information, then restart haproxy:
[root@haproxy-test ~]# systemctl daemon-reload [root@haproxy-test ~]# systemctl restart haproxy
If that change has taken hold, you should see an increase from default of the number of open files allowed for HAProxy (a before and after example is shown below):
[root@haproxy-test ~]# ps ax | grep haproxy 26178 ? Ss 0:00 /usr/local/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid 26181 ? Sl 0:00 /usr/local/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid 26192 pts/0 S+ 0:00 grep --color=auto haproxy [root@haproxy-test ~]# cat /proc/26178/limits | grep open Max open files 222 4096 files [root@haproxy-test ~]# cat /proc/26181/limits | grep open Max open files 4096 4096 files [root@haproxy-test ~]# vi /etc/systemd/system/haproxy.service.d/limits.conf [root@haproxy-test ~]# systemctl daemon-reload [root@haproxy-test ~]# systemctl restart haproxy [root@haproxy-test ~]# ps ax | grep haproxy 26270 ? Ss 0:00 /usr/local/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid 26272 ? Sl 0:00 /usr/local/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid 26281 pts/0 S+ 0:00 grep --color=auto haproxy [root@haproxy-test ~]# cat /proc/26270/limits | grep open Max open files 222 500000 files [root@haproxy-test ~]# cat /proc/26272/limits | grep open Max open files 500000 500000 files [root@haproxy-test ~]# cat /etc/systemd/system/haproxy.service.d/limits.conf [Service] LimitNOFILE=500000 [root@haproxy-test ~]#