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.
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]# lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: CentOS
Description: CentOS Linux release 7.9.2009 (Core)
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.
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):
Unpack the file and change directory into where it was unpacked:
tar xvfz haproxy-2.6.6.tar.gz
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:
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
[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
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:
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'
log 127.0.0.1 local1
# Tune up maxx conns
timeout connect 50000
timeout client 50000
timeout server 50000
server YourServer 127.0.0.1:80
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:
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!
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
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:
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
[root@haproxy-test log]# tail haproxy.log
Mar 1 13:33:28 localhost haproxy: Connect from 127.0.0.1:48342 to 127.0.0.1:80 (ListenName/TCP)
Mar 1 13:33:28 localhost haproxy: Connect from 127.0.0.1:48344 to 127.0.0.1:80 (ListenName/TCP)
Mar 1 13:33:28 localhost haproxy: Connect from 127.0.0.1:48346 to 127.0.0.1:80 (ListenName/TCP)
Mar 1 13:33:28 localhost haproxy: Connect from 127.0.0.1:48348 to 127.0.0.1:80 (ListenName/TCP)
Mar 1 13:33:28 localhost haproxy: Connect from 127.0.0.1:48350 to 127.0.0.1:80 (ListenName/TCP)
Mar 1 13:33:28 localhost haproxy: Connect from 127.0.0.1:48352 to 127.0.0.1:80 (ListenName/TCP)
Mar 1 13:33:28 localhost haproxy: Connect from 127.0.0.1:48354 to 127.0.0.1:80 (ListenName/TCP)
Mar 1 13:33:28 localhost haproxy: Connect from 127.0.0.1:48356 to 127.0.0.1:80 (ListenName/TCP)
Mar 1 13:33:28 localhost haproxy: Connect from 127.0.0.1:48358 to 127.0.0.1:80 (ListenName/TCP)
Mar 1 13:33:28 localhost haproxy: Connect from 127.0.0.1:48360 to 127.0.0.1:80 (ListenName/TCP)
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:
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’):
Place the following setting scope and associated setting in that file:
Once that is done, you will need to direct systemd to reload daemon information, then restart haproxy: