[ZBXNEXT-8014] Provide the binaries for the actual Linux kernel versions and most common PC architecture (amd64) Created: 2022 Oct 05  Updated: 2024 Jun 06

Status: READY TO DEVELOP
Project: ZABBIX FEATURE REQUESTS
Component/s: Packages (C)
Affects Version/s: None
Fix Version/s: 7.0 (plan)

Type: New Feature Request Priority: Major
Reporter: Igor Gorbach (Inactive) Assignee: Alexander Vladishev
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates ZBXNEXT-6849 Static Agent binary for LTS 4.x/5.x k... Open
Team: Team C
Sprint: Sprint 105 (Oct 2023), Sprint 106 (Nov 2023), Sprint 107 (Dec 2023), S2401
Story Points: 1

 Description   

Most common architecture now - amd64

Linux 4.x and 5.x kernels released a time ago

But Zabbix still provides the binaries for the deprecated versions only, the only available option for the amd64 - 3.0

https://www.zabbix.com/download_agents?version=6.0+LTS&release=6.0.9&os=Linux&os_version=3.0&hardware=amd64&encryption=No+encryption&packaging=Archive&show_legacy=1

And this one failed to work on Ubuntu 22, for example, ZBX-21728

Please, provide the binaries for the download page for the actual Linux kernel versions



 Comments   
Comment by Constantin Oshmyan [ 2022 Oct 05 ]

arm64? Probably, misprint, do you mean amd64?

Comment by Constantin Oshmyan [ 2023 Oct 10 ]

alexei, as ZBX-21728 is closed now, this issue becomes the very important for us.
Really, we used to have a lot of different Linux systems; and many of them don't have any repositories officially supported by Zabbix. Some examples:

Up to now, we successfully used a statically-linked Zabbix agents available by the link in the Description part.
However, these agents don't work with the newest Linux kernels
The only alternatives are:

  • to pay money to Zabbix additionally to the standard support contract for obtaining of an agent for a specific platform (as hinted by a support engineer);
  • to compile Zabbix agents from sources by ourselves.

Unfortunately, both variants are bad, especially for appliances (when we don't have compilers and other SDK for that specific platforms).

So, we are kindly asking you to continue to provide statically linked agents, for newest Linux kernels too.

Comment by Constantin Oshmyan [ 2023 Oct 23 ]

Hi guys, I'd like to clarify some moments and to collect here a useful information together.

1. The main purpose of this ticket: to provide a binaries of Zabbix Agent for Linux (zabbix_agentd, as well as supplemental utilities – zabbix_get and zabbix_sender) as portable as possible (independently of specific brand/distro/kernel/etc.).

2. The agent has dependencies on the system library (glibc) and some number of applied libraries (mandatory: pcre2, and optional: curl, ssh, crypto, ldap, etc.).

3. In minimal configuration the only one applied library (pcre2) is necessary; however, some platforms (like VMware Photon and other appliances) don't provide even this library by default. So, it's desirable to have an applied libraries statically linked for portability.

4. As absolutely rightly noted by jlambda in the neighboring ticket, the glibc library, just opposite, should be linked dynamically. This library is very tightly connected to the kernel, so its statically linked version depends on this kernel. Dynamically linked glibc provides much more compatibility (by the way in both directions: backward and forward).

5. Just an example. Result of our experiment: the version of the Zabbix Agent 6.0.22, compiled on the SLES 15 sp5 (kernel 5.14, glibc version 2.31) with the statically linked pcre2 and dynamically linked glibc is compatible with all tested versions of Linux used in our lab, starting with kernel v3.x (see the table below):

Kernel version glibc version Brand Comment Compatibility
2.6.32 2.12 CentOS 6.10 Appliance based on EL6
3.10 2.17 CentOS 7 Appliance based on EL7
3.10 2.17 CentOS 7 IWSVA 6.5 sp3 (appliance based on EL7)
3.10 2.17 RHEL 7.9 RedHat Enterprise Linux
4.4.162 2.22 SLES 12 sp3  
4.12.14 2.22 SLES 12 sp4  
4.12.14 2.22 SLES 12 sp5  
4.15.0 2.27 Ubuntu 18.04.6 LTS (Bionic Beaver)
4.19 2.28 Debian 10 Appliance based on Debian 10
5.4.0 2.31 Ubuntu 20.04.x LTS (Focal Fossa)
5.4.17 2.17 Oracle Linux Server 7.9 Appliance based on Oracle Linux Server 7.9
5.10.175 2.32 VMware Photon 4  
5.14.21 2.31 SLES 15 sp4 and sp5  
5.15.0 2.35 Ubuntu 22.04 LTS (Jammy Jellyfish)

A bit more details: really compatibility depends on the version of glibc (that could depend on the version of kernel). In our example, the binary (build on the system with glibc v2.31) requires glibc v2.14 or above. So, the only incompatible system occurred is the very old CentOS 6 based appliance with the kernel v2.6.32 and glibc v2.12. However, the currently provided by Zabbix built (zabbix_agent-6.0.4-linux-2.6-amd64-static.tar.gz) runs on this platform perfectly.

6. In theory, newer versions of glibc could be incompatible with the older ones. However, in practice, the backward compatibility is supported very long time. For example, glibc v2.31 from SLES 15 sp5 claims about compatibility with the almost all versions starting with 2.2.5 (with some exceptions: 2.19 – 2.21).

7. So, just "for now" it seems that we solved our problem – compiling agents by ourself (I'll describe the procedure a bit later if somebody wants to repeat). It's not very difficult; however, much better to have these binaries available from Zabbix company as official trusted source and with an official support.

Comment by Constantin Oshmyan [ 2023 Oct 24 ]

1) Just some links regarding why statically linking of glibc is a bad idea:

  • faq about glibc
  • discussions on the stackoverflow: one, two and three.
    The last link is interesting because it contains some recommendations if you want lo link to a specific version of glibc (the easiest ways are the last two). However, in my case it is not very important: minimal glibc version 2.14 is quite acceptable for us.

2) Description of the procedure to build the agent.

Introduction

We use the SUSE Linux Enterprise Server (SLES) 15 (sp5 at the moment) as a main Linux platform, so we will build on this platform. Additionally, we are a financial organization, so we have to follow strict requirements from regulatory authorities; therefore we could not just use, for example, the "git" command (it doesn't have direct access to Internet, any downloads we should perform manually via HTTP proxy).

To have a statically linked library, we should build this library from the sources before. The very minimum is the pcre2 library (we will use only it in this example); but if necessary – it's possible to compile and build other optional libraries as well.

We will use the "/opt/" directory for our builds: "/opt/sources/" for source files and just "/opt/" for installed libraries (to not interfere with the standard system paths used during the usual building of Zabbix Server with dynamic libraries).

Building of PCRE2 library

  • download the archive with the sources (in "tar.gz" format) from here and place it into "/tmp/" folder. At the moment it is the file pcre2-10.42.tar.gz.
  • unpack it into the correct place:
    mkdir -p /opt/sources
    cd /opt/sources
    tar xvfz /tmp/pcre2-10.42.tar.gz
    
  • by default, the installation directory is "/usr/local". However, by default this subtree has higher priority during a usual building (for example, when we are compiling the Zabbix Server then). We build a static version of pcre2 for the Agent only, so we don't want install it here; therefore we will install it into "/opt" folder. So, we need the parameter "--prefix=/opt" for the ./configure script.
  • by default, both static and dynamic (shared) libraries are built. We need only static (we already have the shared library from the OS and we don't want to replace it), so we use the "--disable-shared" parameter also.
  • by default, the only 8-bit library is built. It's OK for us (the Zabbix Server also uses the libpcre2-8-0 library only, not 16- or 32-bit versions).
  • just-in-time (JIT) compiling provides a significant performance gains, but is available not for all platforms. To automatically detect if this feature is available, it's recommended to use the "--enable-jit=auto" parameter.
  • so, we build this library using the following commands:
    cd /opt/sources/pcre2*
    ./configure --prefix=/opt --enable-jit=auto --disable-shared
    make
    ./RunTest
    make install
    
  • result: we have the static library in the file "/opt/lib64/libpcre2-8.a" and its description for pkg-config utility (used by the "configure" script of Zabbix) in the file "/opt/lib64/pkgconfig/libpcre2-8.pc".

If we need another libraries, we can build them using the same approach.

Building of Zabbix Agent

  • download from this page the sources of Zabbix (the zabbix-6.0.22.tar.gz file at the moment) and place it to the /tmp/ directory.
  • unpack it into the correct place:
    cd /opt/sources
    tar xvfz /tmp/zabbix-6.0.22.tar.gz
    
  • by default, installation of Zabbix Agent (zabbix_agentd) and supplemental utilities (zabbix_get and zabbix_sener) is performed to the "/usr/local/" directory. It's OK for us; otherwise we also could use the "--prefix=<some_other_dir>" parameter for the "configure" script.
  • by default, the linking with shared libraries is used for all libraries. The "--enable-static" parameter will try to make a completely static binary (using a static version of glibc); it is not that we want. We need the "--enable-static-libs" parameter: it will perform just what we need – make a static linking of all applied libraries, but dynamic linking of the system glibc library.
  • by default, the "configure" script still tries to use an old pcre library. We want to use the newer pcre2 library, moreover – its static version is located in a non-standard location; so we need to point it explicitly.
  • as result, we use the following commands to build and install the agent:
    cd /opt/sources/zabbix*
    # we use the same sources directory to build the Zabbix Server,
    # so we need to clean the "./configure" cache from the previous runs
    [ -f Makefile ] && make distclean
    ./configure --enable-agent \
      --enable-static-libs \
      --with-libpcre2-lib=/opt/lib64
    make
    make install
    # we can strip the resulting binaries to decrease
    # their sizes (by about 1 MB), if we want
    #strip /usr/local/sbin/zabbix_agentd /usr/local/bin/zabbix_{get,sender}
    
Comment by Constantin Oshmyan [ 2024 Jun 06 ]

Hi!

Fix Version/s: 7.0 (plan)

The version 7.0.0 has been released. What is the status of this ticket?

Generated at Wed May 14 08:16:59 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.