Boozlachu May 2 2020 at 17:20

Porting packages to buildroot using the Zabbix example

16 min

4.6K

Configuring Linux*Open source**nix*Development for Linux*Software

Tutorial

The basics of porting

Originally, Buildroot offers a limited number of packages. It makes sense — there is everything you need, but any other packages can be added.

To add a package, create 2 description files, an optional checksum file, and add a link to the package in the general package list. There are hooks at different stages of the build. At the same time, Buildroot can recognize the needed type of packages:

General — the general type packages. In this case, all the commands for the Assembly/installation are written on your own.
Autotools, CMake, Python, Lua, Perl, rebar, waf, meson, cargo(rust), go — easy to collect packages corresponding to their names.
Virtual-packages. This is a type of package that allows you to add functionality provided by one or more packages. For example, OpenGL ES is an API for 2D and 3D graphics in embedded systems. The implementation of this API differs for Allwinner, Tech Sunxi, and Texas Instruments OMAP35xx platforms. Thus, libgles will be a virtual package, and sunxi-mali and ti-gfx will be suppliers.
CKonfig — packages. These are packages that support configuration via kconfig. For example, busybox and Linux-kernel.
Kernel module — a separate type of package for creating your own kernel modules.
Asciidoc — a type of packages for rendering documents from aciidoc to PDF, HTML, and other formats.
There is also an infrastructure for building Linux-kernel-extensions and Linux-kernel-extensions.

All package types are well documented in the Buildroot guide. You can specify different options for getting package source — git, svn, local storage, and others. It's easy to get sources from GitHub. When porting the slim and GitHub packages, we will do so. There is a division into host packages (used only for building other packages that do not fall into the target file system) and packages that fall into the system being built. You can combine this functionality in one package.

Adding patches to the source packages

Sometimes, you need to apply patches to the source packages. There are two ways to do this:

By adding the patch directly to the folder with the package description (${buildroot_root_dir}/package/${packagename}/${patch_file}). It's not very handy if the package is not your own.
By using the directory with global patches. In this case, the patches are stored in a separate folder in my external-tree.

It's the second method that I'll use. The path to the global folder is set in the section Build options → global patch directories. You can set multiple directories. Note that to apply patches to the kernel, it's recommended to use the item Kernel → custom kernel patches. There, you can specify a list of patches as an URL or path to a file/catalog.
You can apply a patch to a single version of the package, or all versions. The difference in the path to the patch:

<global-patch-dir>/<packagename>/<packageversion>/ — apply a patch to a specific version of the package.
<global-patch-dir>/<packagename> overlay the package on all versions of the package.

Package dependencies

The important point is to describe the package dependency. It's described in two files: Config.in (Config.in. host for the hosting package) and ${packagename}.mk.

File Config.in (like Config.in.host) adds the package to the KConfig menu. You can set two types of dependencies: depends on and select.

Depends on — displays the package in the menu only if the specified dependencies are already enabled.

Select works the other way around: if our package is selected, enable the dependency.
Both these dependencies work to generate the build configuration (the .config file in the Buildroot root).

The dependency in the ${packagename}.mk file works differently. During the build stage, Buildroot generates a list of packages to build and install in alphabetical order. And it may happen that, to build a package Apackage, you need a Bpackage package, which will be built, but too late. An error occurs that stops the build.

So, to the file Apackage.mk you need to add this line:

APACKAGE_DEPENDENCIES = BPACKAGE

When the Buildroot reaches the Apackage build and sees the dependency, it'll first build the Bpackage package, and then return to Apackage.

Variables and commands

When writing a make-file with the package build/install rules, you can use variables. The following variables helped me:

$(@D) — the path to the package’s build directory (for example, output/build/demopackage)
$TOPDIR — the root directory of the Buildroot
$BASEDIR — the directory output
\$HOST_DIR, \$STAGING_DIR, \$TARGET_DIR — host fs, staging fs, and target fs build directories
$BUILD_DIR — the directory with unpacked and assembled packages

If you run make help in the Buildroot root, you can learn about additional commands:

Package-specific:
  <pkg>                  - Build and install <pkg> and all its dependencies
  <pkg>-source           - Only download the source files for <pkg>
  <pkg>-extract          - Extract <pkg> sources
  <pkg>-patch            - Apply patches to <pkg>
  <pkg>-depends          - Build <pkg>'s dependencies
  <pkg>-configure        - Build <pkg> up to the configure step
  <pkg>-build            - Build <pkg> up to the build step
  <pkg>-show-info        - generate info about <pkg>, as a JSON blurb
  <pkg>-show-depends     - List packages on which <pkg> depends
  <pkg>-show-rdepends    - List packages which have <pkg> as a dependency
  <pkg>-show-recursive-depends - Recursively list packages on which <pkg> depends
  <pkg>-show-recursive-rdepends - Recursively list packages which have <pkg> as a dependency
  <pkg>-graph-depends    - Generate a graph of <pkg>'s dependencies
  <pkg>-graph-rdepends   - Generate a graph of <pkg>'s reverse dependencies
  <pkg>-dirclean         - Remove <pkg> build directory
  <pkg>-reconfigure      - Restart the build from the configure step
  <pkg>-rebuild          - Restart the build from the build step

Hooks

You can add your hooks at different stages of the package build (from downloading to installation). For a complete list, see the Buildroot documentation.

For example, after installing the demopackage package, I want to run a command that copies the README from the build directory to target-fs. To do this, I make changes to demopackage.mk:

vim package/demopackage/demopackage.mk

First, I’ll set the section with the necessary commands

define DEMOPACKAGE_COPY_README
    cp $(@D)/readme.txt $(TARGET_DIR)/var/demopackage/
endef

And now, I'll add these commands to execute in the post-install-target hook, which are executed after installing the package in target-fs:

DEMOPACKAGE_POST_INSTALL_TARGET_HOOKS += DEMOPACKAGE_COPY_README

This example is very artificial. I recommend paying attention to the section of the article, where I ported the Zabbix package, there is a real application.

Adding a package to the overlay

For convenience, I keep all my developments in the overlay, which is easy to connect to the Buildroot. Read more here

Let's look at the file structure in the overlay that is necessary for adding packages (only the necessary ones are shown):

../overlay/
├── package
│   ├── rodos
│   │   ├── 0001-MAKEFILE-FIX.patch
│   │   ├── Config.in
│   │   └── rodos.mk
│   └── zabbix
│       ├── Config.in
│       ├── zabbix-agent.service
│       ├── zabbix.hash
│       ├── zabbix.mk
│       └── zabbix-server.service
├── external.mk
├── Config.in

Package — the catalog with the packages themselves. There are 2 required files inside — Config.in and ${packagename}.mk. The first is responsible for displaying the KConfig package when configuring the Board; the second contains commands for building the package. It's also helpful to have a ${packagename}.hash file, which contains the hash of the archive with the package sources.

Porting RODOS

The practical part will start with a relatively simple package for the RODOS-5 thermal sensor. The source code is stored on the manufacturer's website as an archive.
To start, I will create the necessary files:

../overlay/
├── package
│   ├── rodos
│   │   ├── 0001-MAKEFILE-FIX.patch
│   │   ├── Config.in
│   │   └── rodos.mk

Config.in — the file from which the menu will be built.

[alexey@comp monitor]$ cat overlay/package/rodos/Config.in
config BR2_PACKAGE_RODOS
    bool "rodos"
    select BR2_PACKAGE_LIBUSB
      help
      rodos 5-6 usb termometer software

The first line specifies the variable associated with the package.
The second sets the type of variable. In my case, this is a Boolean variable. If you add a package to the Board configuration, its value will be equal to y. String variables are also often used for string parameter tasks (for example, paths).
The third adds the LIBUSB package if the RODOS package is being built.
The word help is followed by strings with help output on request.

################################################################################
#
# rodos 5 6
#
################################################################################

RODOS_SOURCE = RODOS5_6.tar.gz
RODOS_SITE = https://silines.ru/software/RODOS/RODOS-5_6
RODOS_DEPENDENCIES += libusb host-libusb

define RODOS_INSTALL_TARGET_CMDS
        $(INSTALL) -D -m 0755 $(@D)/RODOS5_6 $(TARGET_DIR)/usr/bin/RODOS5_6
endef

define RODOS_BUILD_CMDS
    $(TARGET_MAKE_ENV) $(MAKE) $(TARGET_CONFIGURE_OPTS)  CFLAGS="$(TARGET_CFLAGS)" -C $(@D) 
endef

$(eval $(generic-package))

IMPORTANT The names of the set variables must match the package name. In this case, RODOS.
This package is simple; let's look at the structure:

The last line, \$(eval $(generic-package)), sets the package type. In this case, we'll have to set the commands for building and installing the package ourselves. In the case of a cmake package (for example), these commands would follow the rules of the cmake file in the package.

RODOS_SOURCE — the name of the archive that will be downloaded. If you don't specify it, Buildroot will generate the archive name for downloading by its own rules.
RODOS_SITE — the address of the source with source codes. In this case, it's the website address, but it can also be the address of ftp, git, gitlab, svn, and others.
RODOS_DEPENDENCIES — the dependencies required for building the package.

define RODOS_INSTALL_TARGET_CMDS — the section with commands that are used to install the collected files in target-fs.

define RODOS_BUILD_CMDS — commands with package compilation rules. It's important to pay attention to the use of variables.

Special attention should be paid to the 0001-MAKEFILE-FIX.patch file. As previously mentioned, Buildroot can apply patches to packages. In this case, I put the patch directly in the package directory. Between unpacking and building a package, the system applies patches in alphabetical order.

Adding the Zabbix package

The ZABBIX package turned out to be more difficult to port. The package is complex and requires dependency. Below is the version that works. This version not in builroot master branch, but already submitted. It's mandatory to set zabbix-agent; zabbix-server if necessary.

So first, I created the package structure:

tree overlay/package/zabbix/
overlay/package/zabbix/
├── Config.in
├── zabbix-agent.service
├── zabbix.hash
├── zabbix.mk
└── zabbix-server.service

To Config.in and make-file files with the build rules were added the following files:

zabbix.hash This is the file with the checksum of the source archive

cat overlay/package/zabbix/zabbix.hash
# Locally computed
sha256  22bb28e667424ad4688f47732853f4241df0e78a7607727b043d704ba726ae0e  zabbix-4.4.6.tar.gz
sha256  a823e00bc7f0844874f90fee97136f178e7debc76bace5f09e15ee8ed55f04c3  README

The first line indicates that the checksums were not taken from the manufacturer, but calculated independently.

The next 2 lines give the checksums themselves: for the source file and the license file (located inside the source files). This is the requirement of Buildroot itself.

zabbix-agent.service, zabbix-server.service — systemd- the units for starting the agent and server.

Let’s look inside the Config.in:

cat overlay/package/zabbix/Сonfig.in
config BR2_PACKAGE_ZABBIX
        bool "zabbix"
        # Zabbix requires glibc, musl; any other alternative won't work
        # If the condition is not met, the package won't be shown in the Board settings menu
        depends on BR2_TOOLCHAIN_USES_GLIBC=y || BR2_TOOLCHAIN_EXTERNAL_GLIBC=y || BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
        # Adds the pcre package to the system
        select BR2_PACKAGE_PCRE
        help
          Zabbix is an enterprise-class open source distributed
          monitoring solution. Zabbix is free of cost. Zabbix
          is written and distributed under the GPL General Public
          License version 2.

# if glibc is not used, a warning about its necessity is displayed
if (!BR2_TOOLCHAIN_USES_GLIBC && !BR2_TOOLCHAIN_EXTERNAL_GLIBC && !BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC)
comment "zabbix need glibc"
endif

#  If the zabbix package is selected for the build
if BR2_PACKAGE_ZABBIX

# Similar to glibc, but only for zabbix-server
if (!BR2_PACKAGE_POSTGRESQL && !BR2_PACKAGE_MYSQL)
comment "zabbix server needs postgresql or mysql support"
endif

config BR2_PACKAGE_ZABBIX_SERVER
        bool "zabbix server"
        # this way, you can select one of the dependencies
        depends on BR2_PACKAGE_POSTGRESQL || BR2_PACKAGE_MYSQL
        select BR2_PACKAGE_ZLIB
        select BR2_PACKAGE_LIBEVENT

# If the server is selected for the build
if BR2_PACKAGE_ZABBIX_SERVER

# This way, you can select one of the options
choice
        prompt "server database backend"

config BR2_PACKAGE_ZABBIX_SERVER_MYSQL
        bool "mysql"
        depends on BR2_PACKAGE_MYSQL

config BR2_PACKAGE_ZABBIX_SERVER_POSTGRESQL
        bool "postgresql"
        depends on BR2_PACKAGE_POSTGRESQL

endchoice

# This is optional. After this, you can use the variable
 BR2_PACKAGE_ZABBIX_SERVER_COPY_DUMPS
# during the building process. For example, you can call a hook at a certain value of this variable.
if BR2_PACKAGE_ZABBIX_SERVER_POSTGRESQL || BR2_PACKAGE_ZABBIX_SERVER_MYSQL
config BR2_PACKAGE_ZABBIX_SERVER_COPY_DUMPS
        bool "install sql dumps"
        help
          Copy initial database dumps to /usr/zabbix/
endif

# This part is the requirements for the server's web interface.
if (!BR2_PACKAGE_PHP || (!BR2_PACKAGE_PHP_EXT_MYSQLI && !BR2_PACKAGE_PHP_EXT_PGSQL) || \
        !BR2_PACKAGE_PHP_EXT_MBSTRING || !BR2_PACKAGE_PHP_EXT_BCMATH || \
        !BR2_PACKAGE_PHP_EXT_SOCKETS || !BR2_PACKAGE_PHP_EXT_GD || \
        !BR2_PACKAGE_PHP_EXT_LIBXML2 || !BR2_PACKAGE_PHP_EXT_CTYPE || \
        !BR2_PACKAGE_PHP_EXT_SESSION || !BR2_PACKAGE_PHP_EXT_XMLREADER || \
        !BR2_PACKAGE_PHP_EXT_XMLWRITER )
comment "zabbix-frontend need php with extensions(bc, sockets, "
comment "mbstring, gd, libxml2, ctype, session, xmlreader, xmlwriter, mysql or postgresql"
endif

choice
        prompt "server ssl/tls backend"

config BR2_PACKAGE_ZABBIX_SERVER_NOTLS
        bool "none"

config BR2_PACKAGE_ZABBIX_SERVER_OPENSSL
        bool "openssl"
        depends on BR2_PACKAGE_OPENSSL

config BR2_PACKAGE_ZABBIX_SERVER_GNUTLS
        bool "gnutls"
        depends on BR2_PACKAGE_GNUTLS

endchoice

# also optional. These variables will also be used during the build.
# allows you to change the list of dependencies, build rules, call hooks, and redefine them.
# commands for different build stages.
config BR2_PACKAGE_ZABBIX_SERVER_OPENIPMI
        bool "openipmi support"
        select BR2_PACKAGE_OPENIPMI

config BR2_PACKAGE_ZABBIX_SERVER_LIBSSH2
        bool "libssh2 support"
        select BR2_PACKAGE_LIBSSH2

config BR2_PACKAGE_ZABBIX_SERVER_LDAP
        bool "openldap support"
        select BR2_PACKAGE_OPENLDAP

if (!BR2_USE_MMU)
comment "netsnmp support need MMU"
endif

config BR2_PACKAGE_ZABBIX_SERVER_NETSNMP
        bool "net-snmp support"
        depends on BR2_USE_MMU # netsnmp
        select BR2_PACKAGE_NETSNMP

config BR2_PACKAGE_ZABBIX_SERVER_LIBCURL
        bool "libcurl support"
        select BR2_PACKAGE_LIBCURL

config BR2_PACKAGE_ZABBIX_SERVER_LIBXML2
        bool "libxml2 support"
        select BR2_PACKAGE_LIBXML2

# Copying files for the web interface. Many dependencies with complex rules. depends on adds a load on the developer since you need to manually set all the necessary Board settings. At the same time, it guarantees the accuracy of settings and the presence of these packages in the built system.
config BR2_PACKAGE_ZABBIX_SERVER_COPY_FRONTEND
        bool "copy php-frontend to target"
        depends on BR2_PACKAGE_PHP
        depends on BR2_PACKAGE_PHP_EXT_MYSQLI || BR2_PACKAGE_PHP_EXT_PGSQL
        depends on BR2_PACKAGE_PHP_EXT_BCMATH
        depends on BR2_PACKAGE_PHP_EXT_SOCKETS
        depends on BR2_PACKAGE_PHP_EXT_MBSTRING
        depends on BR2_PACKAGE_PHP_EXT_GD
        depends on BR2_PACKAGE_PHP_EXT_LIBXML2
        depends on BR2_PACKAGE_PHP_EXT_CTYPE
        depends on BR2_PACKAGE_PHP_EXT_SESSION
        depends on BR2_PACKAGE_PHP_EXT_XMLREADER
        depends on BR2_PACKAGE_PHP_EXT_XMLWRITER
        help
          copy web-frontend to /usr/zabbix/php-frontend

endif

endif

How it looks in the menu:

[*] zabbix
[*] zabbix server
      server database backend (postgresql)  --->
      [ ]   install sql dumps (NEW)
      *** zabbix-frontend need php with extensions(bc, sockets, ***
      *** mbstring, gd, libxml2, ctype, session, xmlreader, xmlwriter, mysql or postgresql ***
      server ssl/tls backend (none) --->
      [ ]   openipmi support (NEW)
      [ ]   libssh2 support (NEW)
      [ ]   openldap support (NEW)
      [ ]   net-snmp support (NEW)
      [ ]   libcurl support (NEW)
      [ ]   libxml2 support (NEW)

And the choice of database (within the zabbix server database backend):

( ) Use mysql support
(X) Use postgresql support

Then, you'll need an explanation of what, how, and why I did it.

zabbix — installing the Zabbix package. Initially, the agent is set, and if necessary, the server is set.
zabbix server — installing the Zabbix server — an important point. The server requires a database (postgresql or mysql), but it may be on a different host. However, you'll need the package to build it. TK is a mandatory requirement; I added the option depends on.

install sql dumps — this option allows you to copy the sql dumps needed to create a Zabbix database.

ZABBIX can support various features, such as working with ldap, openipmi, and so on. For all this, it needs header files and/or a library of corresponding packages — openldap, openipmi.

Make-file with build instructions (note that the variable names start with the package name and match the variable names I used above):

################################################################################
#
#zabbix
#
################################################################################

# Package version. This is important because it's used to build the file name for downloading
# Learn more here https://buildroot.org/downloads/manual/manual.html#generic-package-reference
ZABBIX_VERSION = 4.4.6
# Source where the source codes will be downloaded from
ZABBIX_SITE = https://sourceforge.net/projects/zabbix/files
# License type and file with it
ZABBIX_LICENSE = GPL-2.0
ZABBIX_LICENSE_FILES = README
# Dependencies
ZABBIX_DEPENDENCIES = pcre
# List of options for configuration and build.
ZABBIX_CONF_OPTS = --with-libpcre=$(STAGING_DIR)/usr/bin/ \
    --enable-agent

# An interesting point is an example of using hooks.
# To change the configuration file, I need to run sed after installing the files.
# First, you need to declare a set of commands, then add their call to hooks.
# I'll declare the commands first. Note that the sed call is from the toolchain, not the system.
define ZABBIX_CLIENT_CHANGE_PIDFILE_LOCATION
    $(SED) 's%\#\ PidFile=/tmp/zabbix_agentd.pid%PidFile=/run/zabbix/zabbix_agentd.pid%g' $(TARGET_DIR)/etc/zabbix_agentd.conf
endef
# And now I'll add this set of commands to the hook that is executed after installation in the target
ZABBIX_POST_INSTALL_TARGET_HOOKS += ZABBIX_CLIENT_CHANGE_PIDFILE_LOCATION

# Canonical method for installing systemd units and autorun them in multi-user.targer
# To add UNIT, just add the file name to the ZABBIX_SYSTEMD_UNITS variable
# For example, ZABBIX_SYSTEMD_UNITS += zabbix-agent.service
# First, I'll add the file to the list
ZABBIX_SYSTEMD_UNITS += zabbix-agent.service
# Then I'll install them.
define ZABBIX_INSTALL_INIT_SYSTEMD
    $(foreach unit,$(ZABBIX_SYSTEMD_UNITS),\
        $(INSTALL) -D -m 0644 $(ZABBIX_PKGDIR)/$(unit) $(TARGET_DIR)/usr/lib/systemd/system/$(unit) && \
        mkdir -p $(TARGET_DIR)/etc/systemd/system/multi-user.target.wants && \
        ln -fs -r $(TARGET_DIR)/usr/lib/systemd/system/$(unit) $(TARGET_DIR)/etc/systemd/system/multi-user.target.wants/$(unit)
    )
endef

# This is the correct way to add a user to the system
define ZABBIX_USERS
    zabbix -1 zabbix -1 !- /var/lib/zabbix - zabbix zabbix user
endef

# An example of using a variable from Config.in. If the server is selected for installation, the following steps are performed
ifeq ($(BR2_PACKAGE_ZABBIX_SERVER),y)
# Adding another systemd unit-file
ZABBIX_SYSTEMD_UNITS += zabbix-server.service
# Adding build options to existing ones
ZABBIX_CONF_OPTS += --enable-server \
    --with-libevent \
    --with-libpthread=$(STAGING_DIR)/usr \
    --with-zlib=$(STAGING_DIR)/usr
# Also, add the dependencies
ZABBIX_DEPENDENCIES += libevent zlib
# Using hooks again - adding another set of commands to the list
ZABBIX_POST_INSTALL_TARGET_HOOKS += ZABBIX_SERVER_CHANGE_PIDFILE_LOCATION

# Support for one of the options, particularly openipmi.
# I also check the value of the variable, add build options and dependencies, and call hooks
# Need openipmi in staging dir. Patch submitted in 2019.12.16
# Before this patch is enabled, use this crutch
ifeq ($(BR2_PACKAGE_ZABBIX_SERVER_OPENIPMI),y)
ZABBIX_CONF_OPTS += --with-openipmi=$(STAGING_DIR)/usr
ZABBIX_DEPENDENCIES += openipmi
ZABBIX_PRE_CONFIGURE_HOOKS += BR2_PACKAGE_ZABBIX_SERVER_OPENIPMI_FIX_LIBS

define BR2_PACKAGE_ZABBIX_SERVER_OPENIPMI_FIX_LIBS
    if [ ! -f $(STAGING_DIR)/usr/lib/libOpenIPMI.so ]; then \
        cp -rf $(TARGET_DIR)/usr/lib/libOpenIPMI* $(STAGING_DIR)/usr/lib/ ;\
        cp -rf $(TARGET_DIR)/usr/include/OpenIPMI $(STAGING_DIR)/usr/include/ ;\
    fi
endef
endif

ifeq ($(BR2_PACKAGE_ZABBIX_SERVER_LIBCURL),y)
ZABBIX_CONF_OPTS += --with-libcurl=$(STAGING_DIR)/usr/bin/curl-config
ZABBIX_DEPENDENCIES += libcurl
endif

ifeq ($(BR2_PACKAGE_ZABBIX_SERVER_LIBXML2),y)
ZABBIX_CONF_OPTS += --with-libxml2=$(STAGING_DIR)/usr/bin/xml2-config
ZABBIX_DEPENDENCIES += libxml2
endif

ifeq ($(BR2_PACKAGE_ZABBIX_SERVER_NETSNMP),y)
ZABBIX_CONF_OPTS += --with-net-snmp=$(STAGING_DIR)/usr/bin/net-snmp-config
ZABBIX_DEPENDENCIES += netsnmp
endif

ifeq ($(BR2_PACKAGE_ZABBIX_SERVER_LDAP),y)
ZABBIX_CONF_OPTS += --with-ldap=$(STAGING_DIR)/usr
ZABBIX_DEPENDENCIES += openldap
endif

ifeq ($(BR2_PACKAGE_ZABBIX_SERVER_LIBSSH2),y)
ZABBIX_CONF_OPTS += --with-ssh2=$(STAGING_DIR)/usr
ZABBIX_DEPENDENCIES += libssh2
endif

ifeq ($(BR2_PACKAGE_ZABBIX_SERVER_OPENSSL),y)
ZABBIX_CONF_OPTS += --with-openssl=$(STAGING_DIR)/usr
ZABBIX_DEPENDENCIES += openssl
else ifeq ($(BR2_PACKAGE_ZABBIX_SERVER_GNUTLS),y)
ZABBIX_CONF_OPTS += --with-gnutls=$(STAGING_DIR)/usr
ZABBIX_DEPENDENCIES += gnutls
endif

ifeq ($(BR2_PACKAGE_ZABBIX_SERVER_COPY_FRONTEND),y)
ZABBIX_POST_INSTALL_TARGET_HOOKS += ZABBIX_SERVER_COPY_FRONTEND

define ZABBIX_SERVER_COPY_FRONTEND
    mkdir -p $(TARGET_DIR)/usr/zabbix/php-frontend/
    cp -r $(@D)/frontends/php/* $(TARGET_DIR)/usr/zabbix/php-frontend/
endef

endif

define ZABBIX_SERVER_CHANGE_PIDFILE_LOCATION
    $(SED) 's%\#\ PidFile=/tmp/zabbix_server.pid%PidFile=/run/zabbix/zabbix_server.pid%g' $(TARGET_DIR)/etc/zabbix_server.conf
endef

ifeq ($(BR2_PACKAGE_ZABBIX_SERVER_MYSQL),y)
ZABBIX_DEPENDENCIES += mysql
ZABBIX_CONF_OPTS += --with-mysql=$(STAGING_DIR)/usr/bin/mysql_config
# Need package/mariadb/0003-add-sysroot-path-to-mariadb_config.patch by Ryan Coe
# While this patch is not included, use this crutch
ZABBIX_PRE_CONFIGURE_HOOKS += ZABBIX_DISABLE_MARIADB_CONFIG
ZABBIX_POST_CONFIGURE_HOOKS += ZABBIX_ENABLE_MARIADB_CONFIG

define ZABBIX_DISABLE_MARIADB_CONFIG
    if [ -f "$(STAGING_DIR)/usr/bin/mariadb_config" ]; then \
        mv $(STAGING_DIR)/usr/bin/mariadb_config $(STAGING_DIR)/usr/bin/mariadb_config_save; \
    fi
endef

define ZABBIX_ENABLE_MARIADB_CONFIG
    if [ -f "$(STAGING_DIR)/usr/bin/mariadb_confi_save" ]; then \
        mv $(STAGING_DIR)/usr/bin/mariadb_config_save $(STAGING_DIR)/usr/bin/mariadb_config; \
    fi
endef

ifeq ($(BR2_PACKAGE_ZABBIX_SERVER_COPY_DUMPS),y)
ZABBIX_POST_INSTALL_TARGET_HOOKS += ZABBIX_SERVER_PREPARE_MYSQL
endif

define ZABBIX_SERVER_PREPARE_MYSQL
    mkdir -p $(TARGET_DIR)/usr/zabbix/mysql_schema/
    cp -r $(@D) $(@D)/database/mysql/*\.sql $(TARGET_DIR)/usr/zabbix/mysql_schema/
endef

endif

ifeq ($(BR2_PACKAGE_ZABBIX_SERVER_POSTGRESQL),y)
ZABBIX_DEPENDENCIES += postgresql
ZABBIX_CONF_OPTS += --with-postgresql=$(STAGING_DIR)/usr/bin/pg_config

define ZABBIX_SERVER_PREPARE_POSTGRESQL
    mkdir -p $(TARGET_DIR)/usr/zabbix/postgresql_schema
    cp -r $(@D)/database/postgresql/*\.sql $(TARGET_DIR)/usr/zabbix/postgresql_schema/
endef

ifeq ($(BR2_PACKAGE_ZABBIX_SERVER_COPY_DUMPS),y)
ZABBIX_POST_INSTALL_TARGET_HOOKS += ZABBIX_SERVER_PREPARE_POSTGRESQL
endif

endif

endif
# I set the package type. In this case, autotools will be used.
$(eval $(autotools-package))

When installing the package, zabbix-agent and its dependencies will also be installed. The location of its pid-file will be changed, and the systemd UNIT file will be installed with its autorun in multi-user.target.

Optionally, you can also install zabbix-server. But then DBMS will be selected for installation, and the dump files with initial data (optional), as well as the web-frontend files (also optional), will be copied to the target system.

I specifically didn't add a web server installation. First, it can be located on another computer. Secondly, there are a lot of options for a web server; if you'll need it — you'll install the right one with the necessary php modules.

Conclusion

As you can see from the text above, it's quite possible to port packages to the Buildroot by yourself. There are powerful mechanisms that automate the build. At the same time, it's possible to intervene in the build process at any time and change the necessary moments.

Tags:

Hubs: