Why does the zabbix agent have dependencies ? VERY BAD Idea !!

[NE1Scott]

Why has the Zabbix community decided that having a Linux agent with dependencies is a good idea.

You've basically eliminated anybody with build slaves or a strictly controlled production environment from using the linux agent.

I have at least 39 of my most critical servers that I can only monitor via ICMP because the agent is requiring libcrypt.so.10 to be opdated or openssl to be updated in order for the agent to install.
This is totally unacceptable.

For my build environment and my production environment which are both multi-layer firewalled on private VLANs with no inbound internet access, zero changes are allowed since the build environment and production environment are required to stay exactly as they are until the dev team investigates the impact of any changes to the system. This would require a major reason to need to make modification of which the zabbix agent is not in their eyes versus the man-hours involved in testing the systems with update libraries.

A properly thought out Zabbix Agent build would have all of it's dependencies built into the build so it could ALWAYS install and not rely on libraries or packages from the local system regardless of linux version and updates.

For now I can only monitor the really important servers with ICMP unless they required no updates. This means I can really only use the zabbix agent most of the time on systems nobody gives a damn about installing updates on.

Here are 3 of the messages received:
error: Failed dependencies:
libcrypto.so.10(OPENSSL_1.0.1) is needed by zabbix-agent-5.0.2-1.el6.i686

error: Failed dependencies:
libcrypto.so.10(OPENSSL_1.0.2)(64bit) is needed by zabbix-agent-5.0.2-1.el7.x86_64

error: Failed Dependencies:
Openssl 1:1.0.2k-21.el7_9 needs installed

39 of my first 128 hosts have this issue which is very frusttrating because they are hte MOST IMPORTANT servers/VMs to monitor.

As you can tell I am very frustrated by this and doen't undeerstand what the thinking behind it is except for some idiot trying to force people to update to the newer versions quoting security or some other justification.
In a production environment sometimes the simplest updates require a complete reinstall and reconfiguration of ALL systems involved which can take 6 months to a year.

[gofree]

As you have outdated systems you can always try to install zabbix agent version 4 ( LTS - still supported ), its better than icmp and might work with the older openssl. In the meantime maybe you can update your systems ( internet is not necessary to install zabbbix agents ).

In a production environment sometimes the simplest updates require a complete reinstall and reconfiguration of ALL systems involved which can take 6 months to a year.

Never seen that, nor saying its not possible. Bot I think something needs to be done - that is not a good design

[NE1Scott]

There are too many diferent dev groups within the multiple companies I support (7) with too many projects to ask them all to update openssl and/or libcrypto.so.10 and retest their software.
While they might be willing to introduce this change as part of a new build project it would be months before that gets deployed to production.
I have put out a notice to these dev groups asking them to update openssl and libcrypto.so.10 or move to RHEL7.5 or newer.

While small updates to the OS would be considered, a jump to the latest minor version would probably be favored to move things to Redhat 7.8.x (or whatever is the latest 7.x).
Yet another new project might possibly be launched for redhat 8.x but it would be lower priority.

I will take a look at the older Zabbix agents. I am running Zabbix server 5.0.2 so I guess I could try the final 4.x.x agent release.

[NE1Scott]

It's just frustrating that it's not the equivalent of a self contained executable so I don't need to worry about these issues or potential conflicts with libraries.

[gofree]

you could also try compile it yourself statically or do any other magic as its opensource code, don't complain that you bought a red car when you wanted a helicopter its all documented, no hidden catch

https://www.zabbix.com/documentation/current/manual/installation/install

[tim.mooney]

Why has the Zabbix community decided that having a Linux agent with dependencies is a good idea.

You've basically eliminated anybody with build slaves or a strictly controlled production environment from using the linux agent.

I have at least 39 of my most critical servers that I can only monitor via ICMP because the agent is requiring libcrypt.so.10 to be opdated or openssl to be updated in order for the agent to install.
This is totally unacceptable.

Sorry, but you're looking at things from one particular, very narrow perspective. That's caused you to come to an incorrect conclusion.

The pre-packaged binaries for a particular distro and version should be built to support that distro and version. That covers the needs of the widest group of people.

If you are running systems that have different needs, because of some organizational policy specific to your install, then the best course of action is for you to build your own custom binaries or packages from the freely available and open source. You can tailor the build in many different ways, at least one of which is likely to meet your particular needs.

For something that's more self-contained, you could also look at the docker images, but considering you're trying to use RHEL 6 packages, docker probably isn't an option for you. Hence my suggestion that you custom build your own binaries or packages.

[NE1Scott]

I understand you point of view as well but since I am not a programmer that is really probably not an option for myself.

I realize the code would be bigger but it frustrates me that something that you are supposed to be able to install unobtrusively to monitor systems that most likely are under the perview of people that that don't want anything installed on their systems, relied on ridgid dependencies rather that just containing everything it needs to get the job done.

At this point I will try the latest 4.x binaries to see if that works for me, otherwise I would need a tarball in the rpmbuild format to be able to revbuild it with my limited programming knowledge.
We do not allow software to be installed via make/make install, only via yum/rpm/apt so it is managed.

[NE1Scott]

We are at 585 systems/devices added and still adding more weekly to what we are monitoring from 14 dev/prod groups.

[otheus]

I'm agreeing with the OP here. And I'm noticing that Zabbix 6.0 made the problem MUCH MUCH worse. When installing the zabbix-agent on a base RHEL9 system, I get:

Installing:
 zabbix-agent                    x86_64    1:6.0.36-1.el9        uibk_EPEL_EPEL_9_RPM_x86_64         294 k
Upgrading:
 gnupg2                          x86_64    2.3.3-4.el9           rhel-9-for-x86_64-baseos-rpms       2.5 M
 libcurl                         x86_64    7.76.1-19.el9_1.2     rhel-9-for-x86_64-baseos-rpms       287 k
 libldb                          x86_64    2.5.2-1.el9           rhel-9-for-x86_64-baseos-rpms       191 k
 libnfsidmap                     x86_64    1:2.5.4-27.el9        rhel-9-for-x86_64-baseos-rpms        65 k
 libsemanage                     x86_64    3.6-2.1.el9_5         rhel-9-for-x86_64-baseos-rpms       120 k
 libsss_certmap                  x86_64    2.9.5-4.el9_5.4       rhel-9-for-x86_64-baseos-rpms        94 k
 libsss_idmap                    x86_64    2.9.5-4.el9_5.4       rhel-9-for-x86_64-baseos-rpms        44 k
 libsss_nss_idmap                x86_64    2.9.5-4.el9_5.4       rhel-9-for-x86_64-baseos-rpms        48 k
 libsss_sudo                     x86_64    2.9.5-4.el9_5.4       rhel-9-for-x86_64-baseos-rpms        37 k
 libtdb                          x86_64    1.4.10-1.el9          rhel-9-for-x86_64-baseos-rpms        52 k
 libtevent                       x86_64    0.16.1-1.el9          rhel-9-for-x86_64-baseos-rpms        49 k
 libuser                         x86_64    0.63-15.el9           rhel-9-for-x86_64-baseos-rpms       417 k
 openldap                        x86_64    2.6.6-3.el9           rhel-9-for-x86_64-baseos-rpms       286 k
 sssd-client                     x86_64    2.9.5-4.el9_5.4       rhel-9-for-x86_64-baseos-rpms       173 k
 sssd-common                     x86_64    2.9.5-4.el9_5.4       rhel-9-for-x86_64-baseos-rpms       1.6 M
 sssd-kcm                        x86_64    2.9.5-4.el9_5.4       rhel-9-for-x86_64-baseos-rpms       113 k
 sssd-nfs-idmap                  x86_64    2.9.5-4.el9_5.4       rhel-9-for-x86_64-baseos-rpms        42 k
 sudo                            x86_64    1.9.5p2-10.el9_3      rhel-9-for-x86_64-baseos-rpms       1.1 M
Installing dependencies:
 checkpolicy                     x86_64    3.6-1.el9             rhel-9-for-x86_64-appstream-rpms    357 k
 policycoreutils-python-utils    noarch    3.6-2.1.el9           rhel-9-for-x86_64-appstream-rpms     81 k
 python3-audit                   x86_64    3.0.7-101.el9_0.2     rhel-9-for-x86_64-appstream-rpms     86 k
 python3-distro                  noarch    1.5.0-7.el9           rhel-9-for-x86_64-appstream-rpms     40 k
 python3-libsemanage             x86_64    3.6-2.1.el9_5         rhel-9-for-x86_64-appstream-rpms     81 k
 python3-policycoreutils         noarch    3.6-2.1.el9           rhel-9-for-x86_64-appstream-rpms    2.1 M
 python3-setools                 x86_64    4.4.4-1.el9           rhel-9-for-x86_64-baseos-rpms       609 k
 zabbix                          x86_64    1:6.0.36-1.el9        uibk_EPEL_EPEL_9_RPM_x86_64         729 k
 zabbix-selinux                  noarch    1:6.0.36-1.el9        uibk_EPEL_EPEL_9_RPM_x86_64          28 k

This trend really must stop. And with respect Mr Mooney, your perspective justifies the _opposite_ conclusion: that the widest variety of systems are those that have the fewest dependencies. The agent has a plugin architecture, and it should be used accordingly.

FYI: The dependency on 'zabbix' is very strange. This requirement pulls in 'zabbix-selinux' which pulls in all the checkpolicy and python3 crap. That's a bit sloppy. Either selinux should be an optional package for those who care about it, or it should be done without all the dependencies, like every other tool that gets installed without needing these.

[mrnobody]

When i have the same situation, hosts that is restricted (FW, IDS, etc), and Agent solutions could become a unavaible or even a problem. I extend the native SNMP and create new OID's, so i don't depend of agent. I craft my own "agent". Could be a option... Good luck!

[tim.mooney]

I'm agreeing with the OP here. And I'm noticing that Zabbix 6.0 made the problem MUCH MUCH worse. When installing the zabbix-agent on a base RHEL9 system, I get:

Installing:
zabbix-agent x86_64 1:6.0.36-1.el9 uibk_EPEL_EPEL_9_RPM_x86_64 294 k
Upgrading:
gnupg2 x86_64 2.3.3-4.el9 rhel-9-for-x86_64-baseos-rpms 2.5 M
libcurl x86_64 7.76.1-19.el9_1.2 rhel-9-for-x86_64-baseos-rpms 287 k
libldb x86_64 2.5.2-1.el9 rhel-9-for-x86_64-baseos-rpms 191 k
libnfsidmap x86_64 1:2.5.4-27.el9 rhel-9-for-x86_64-baseos-rpms 65 k
libsemanage x86_64 3.6-2.1.el9_5 rhel-9-for-x86_64-baseos-rpms 120 k
libsss_certmap x86_64 2.9.5-4.el9_5.4 rhel-9-for-x86_64-baseos-rpms 94 k
libsss_idmap x86_64 2.9.5-4.el9_5.4 rhel-9-for-x86_64-baseos-rpms 44 k
libsss_nss_idmap x86_64 2.9.5-4.el9_5.4 rhel-9-for-x86_64-baseos-rpms 48 k
libsss_sudo x86_64 2.9.5-4.el9_5.4 rhel-9-for-x86_64-baseos-rpms 37 k
libtdb x86_64 1.4.10-1.el9 rhel-9-for-x86_64-baseos-rpms 52 k
libtevent x86_64 0.16.1-1.el9 rhel-9-for-x86_64-baseos-rpms 49 k
libuser x86_64 0.63-15.el9 rhel-9-for-x86_64-baseos-rpms 417 k
openldap x86_64 2.6.6-3.el9 rhel-9-for-x86_64-baseos-rpms 286 k
sssd-client x86_64 2.9.5-4.el9_5.4 rhel-9-for-x86_64-baseos-rpms 173 k
sssd-common x86_64 2.9.5-4.el9_5.4 rhel-9-for-x86_64-baseos-rpms 1.6 M
sssd-kcm x86_64 2.9.5-4.el9_5.4 rhel-9-for-x86_64-baseos-rpms 113 k
sssd-nfs-idmap x86_64 2.9.5-4.el9_5.4 rhel-9-for-x86_64-baseos-rpms 42 k
sudo x86_64 1.9.5p2-10.el9_3 rhel-9-for-x86_64-baseos-rpms 1.1 M
Installing dependencies:
checkpolicy x86_64 3.6-1.el9 rhel-9-for-x86_64-appstream-rpms 357 k
policycoreutils-python-utils noarch 3.6-2.1.el9 rhel-9-for-x86_64-appstream-rpms 81 k
python3-audit x86_64 3.0.7-101.el9_0.2 rhel-9-for-x86_64-appstream-rpms 86 k
python3-distro noarch 1.5.0-7.el9 rhel-9-for-x86_64-appstream-rpms 40 k
python3-libsemanage x86_64 3.6-2.1.el9_5 rhel-9-for-x86_64-appstream-rpms 81 k
python3-policycoreutils noarch 3.6-2.1.el9 rhel-9-for-x86_64-appstream-rpms 2.1 M
python3-setools x86_64 4.4.4-1.el9 rhel-9-for-x86_64-baseos-rpms 609 k
zabbix x86_64 1:6.0.36-1.el9 uibk_EPEL_EPEL_9_RPM_x86_64 729 k
zabbix-selinux noarch 1:6.0.36-1.el9 uibk_EPEL_EPEL_9_RPM_x86_64 28 k

This trend really must stop. And with respect Mr Mooney, your perspective justifies the _opposite_ conclusion: that the widest variety of systems are those that have the fewest dependencies. The agent has a plugin architecture, and it should be used accordingly.

You're installing the EPEL build of zabbix-agent, which may have a different set of dependencies than the official packages. Try the official package to see if you get the same results.

You're equating the dependencies being worse because of Zabbix 6,x, but at least some of that might be because of the dependency hierarchy for RHEL 9.

There aren't many plugins for the traditional agent, though it's technically possible to do. The Zabbix developers seem to be focusing more on the Go-based zabbix_agent2, which does have a lot more plugins.

Zabbix is completely open source, including the source packages, so it's possible to tailor the agent to be closer to what your environment requires.

[Brambo]

I'm agreeing with the OP here. And I'm noticing that Zabbix 6.0 made the problem MUCH MUCH worse. When installing the zabbix-agent on a base RHEL9 system, I get:

Installing:
zabbix-agent x86_64 1:6.0.36-1.el9 uibk_EPEL_EPEL_9_RPM_x86_64 294 k
Upgrading:
gnupg2 x86_64 2.3.3-4.el9 rhel-9-for-x86_64-baseos-rpms 2.5 M
libcurl x86_64 7.76.1-19.el9_1.2 rhel-9-for-x86_64-baseos-rpms 287 k
libldb x86_64 2.5.2-1.el9 rhel-9-for-x86_64-baseos-rpms 191 k
libnfsidmap x86_64 1:2.5.4-27.el9 rhel-9-for-x86_64-baseos-rpms 65 k
libsemanage x86_64 3.6-2.1.el9_5 rhel-9-for-x86_64-baseos-rpms 120 k
libsss_certmap x86_64 2.9.5-4.el9_5.4 rhel-9-for-x86_64-baseos-rpms 94 k
libsss_idmap x86_64 2.9.5-4.el9_5.4 rhel-9-for-x86_64-baseos-rpms 44 k
libsss_nss_idmap x86_64 2.9.5-4.el9_5.4 rhel-9-for-x86_64-baseos-rpms 48 k
libsss_sudo x86_64 2.9.5-4.el9_5.4 rhel-9-for-x86_64-baseos-rpms 37 k
libtdb x86_64 1.4.10-1.el9 rhel-9-for-x86_64-baseos-rpms 52 k
libtevent x86_64 0.16.1-1.el9 rhel-9-for-x86_64-baseos-rpms 49 k
libuser x86_64 0.63-15.el9 rhel-9-for-x86_64-baseos-rpms 417 k
openldap x86_64 2.6.6-3.el9 rhel-9-for-x86_64-baseos-rpms 286 k
sssd-client x86_64 2.9.5-4.el9_5.4 rhel-9-for-x86_64-baseos-rpms 173 k
sssd-common x86_64 2.9.5-4.el9_5.4 rhel-9-for-x86_64-baseos-rpms 1.6 M
sssd-kcm x86_64 2.9.5-4.el9_5.4 rhel-9-for-x86_64-baseos-rpms 113 k
sssd-nfs-idmap x86_64 2.9.5-4.el9_5.4 rhel-9-for-x86_64-baseos-rpms 42 k
sudo x86_64 1.9.5p2-10.el9_3 rhel-9-for-x86_64-baseos-rpms 1.1 M
Installing dependencies:
checkpolicy x86_64 3.6-1.el9 rhel-9-for-x86_64-appstream-rpms 357 k
policycoreutils-python-utils noarch 3.6-2.1.el9 rhel-9-for-x86_64-appstream-rpms 81 k
python3-audit x86_64 3.0.7-101.el9_0.2 rhel-9-for-x86_64-appstream-rpms 86 k
python3-distro noarch 1.5.0-7.el9 rhel-9-for-x86_64-appstream-rpms 40 k
python3-libsemanage x86_64 3.6-2.1.el9_5 rhel-9-for-x86_64-appstream-rpms 81 k
python3-policycoreutils noarch 3.6-2.1.el9 rhel-9-for-x86_64-appstream-rpms 2.1 M
python3-setools x86_64 4.4.4-1.el9 rhel-9-for-x86_64-baseos-rpms 609 k
zabbix x86_64 1:6.0.36-1.el9 uibk_EPEL_EPEL_9_RPM_x86_64 729 k
zabbix-selinux noarch 1:6.0.36-1.el9 uibk_EPEL_EPEL_9_RPM_x86_64 28 k

This trend really must stop. And with respect Mr Mooney, your perspective justifies the _opposite_ conclusion: that the widest variety of systems are those that have the fewest dependencies. The agent has a plugin architecture, and it should be used accordingly.

FYI: The dependency on 'zabbix' is very strange. This requirement pulls in 'zabbix-selinux' which pulls in all the checkpolicy and python3 crap. That's a bit sloppy. Either selinux should be an optional package for those who care about it, or it should be done without all the dependencies, like every other tool that gets installed without needing these.

For someone who is kicking up a 4 year old thread you must have read the topic and see the comments that you are free to build your own agent version from source code.
When that is no option due to skill set then hire someone to do that for you.(maybe your regional zabbix training institutions can help you with that)
Third option, which i give very close to zero chance: write a very compelling business case why Zabbix should chance this approach and how much you are willing to invest on that.