Zabbix 4.0 on CentOS 7 - Missing dependency in Epel (libiksemel)

[Janto]

I was just trying to install Zabbix 4.0 from the official Zabbix RHEL repositories on a freshly setup CentOS 7 host. As it seems, the guys over at Epel recently removed the package for iksemel due to security reasons, stated at https://bugzilla.redhat.com/show_bug.cgi?id=1594986

Installation of Zabbix Server package fails:

[root@monitor ~]# yum install zabbix-server-mysql
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.fra10.de.leaseweb.net
* epel: mirror.de.leaseweb.net
* extras: mirror.ratiokontakt.de
* updates: mirror.ratiokontakt.de
Resolving Dependencies
--> Running transaction check
---> Package zabbix-server-mysql.x86_64 0:4.0.0-2.el7 will be installed
--> Processing Dependency: fping for package: zabbix-server-mysql-4.0.0-2.el7.x86_64
--> Processing Dependency: libnetsnmp.so.31()(64bit) for package: zabbix-server-mysql-4.0.0-2.el7.x86_64
--> Processing Dependency: libiksemel.so.3()(64bit) for package: zabbix-server-mysql-4.0.0-2.el7.x86_64
--> Processing Dependency: libOpenIPMIposix.so.0()(64bit) for package: zabbix-server-mysql-4.0.0-2.el7.x86_64
--> Processing Dependency: libOpenIPMI.so.0()(64bit) for package: zabbix-server-mysql-4.0.0-2.el7.x86_64
--> Processing Dependency: libodbc.so.2()(64bit) for package: zabbix-server-mysql-4.0.0-2.el7.x86_64
--> Running transaction check
---> Package OpenIPMI-libs.x86_64 0:2.0.23-2.el7 will be installed
--> Processing Dependency: OpenIPMI-modalias = 2.0.23-2.el7 for package: OpenIPMI-libs-2.0.23-2.el7.x86_64
---> Package fping.x86_64 0:3.10-4.el7 will be installed
---> Package net-snmp-libs.x86_64 1:5.7.2-33.el7_5.2 will be installed
---> Package unixODBC.x86_64 0:2.3.1-11.el7 will be installed
--> Processing Dependency: libltdl.so.7()(64bit) for package: unixODBC-2.3.1-11.el7.x86_64
---> Package zabbix-server-mysql.x86_64 0:4.0.0-2.el7 will be installed
--> Processing Dependency: libiksemel.so.3()(64bit) for package: zabbix-server-mysql-4.0.0-2.el7.x86_64
--> Running transaction check
---> Package OpenIPMI-modalias.x86_64 0:2.0.23-2.el7 will be installed
---> Package libtool-ltdl.x86_64 0:2.4.2-22.el7_3 will be installed
---> Package zabbix-server-mysql.x86_64 0:4.0.0-2.el7 will be installed
--> Processing Dependency: libiksemel.so.3()(64bit) for package: zabbix-server-mysql-4.0.0-2.el7.x86_64
--> Finished Dependency Resolution
Error: Package: zabbix-server-mysql-4.0.0-2.el7.x86_64 (zabbix)
Requires: libiksemel.so.3()(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

Will fixed binary packages without libiksemel dependency provided any time soon, or do we have to build our own packages from source?

Cheers,
Janto

[ingus.vilnis]

Hello and welcome to Zabbix forums!

The request to fix this problem is here https://support.zabbix.com/browse/ZBXNEXT-2842 but no ETA know.

However you can stil install the server using the "non-supported" Zabbix repo which has the libiksemel packages too. http://repo.zabbix.com/non-supported/

[Janto]

Ingus, thanks for the hint regarding the non-supported repository (worked) and the pointer to the ZBXNEXT issue. Seeing it was opened in 2016, and following the comments in the issue, I don't believe this will be fixed any time soon.

I don't use Jabber/XMMP notifications, so I hope this piece of code implemented by libiksemel will not run any time on my server.

[NOB]

Hi Janto

these problems are exactly why I don't like any prepared packages of all kinds.
There is the all-in-one approach where you install all possible dependencies and their dependencies and so on.
And suddenly you are facing these problems.
Or there could be a minimal version, which is not sufficient for most of the users.

I do the packaging, patching and so on myself. For several Linux versions like RedHat5 (32 and 64-bit), RedHat6, RedHat7, Suse Linux,
Oracle Linux, Solaris and Windows.
E.g. the RedHat7 agent package for 3.0.x does not work on Oracle Linux with certain configurations of the agent like
setting the hostname to the corresponding item.
You'll get "localhost.localdomain" almost every time !

I once installed a simple application and ended up in adding ghostscript to my system.
In the same way you ended up with an installation of a package you don't need and which has, obviously,
a security issue.

I still have to patch every Proxy source, anyway, because there is no difference between SourceIP (all communications with agents and server
follow this rule) and our requirement of InterNodeIP (different IP/interface for communication with the server vs. agents).

Kind regards
Norbert

[Jason]

If you're building your own and don't need jabber support then you don't need libiksmel and it's simple to remove from the .spec file. It might be worth changing the default server build to not have this package and then providing another version for those that really must have it. Having a deprecated and insecure package installed by default has the potential to cause issues in future.

[Vaku]

I do the packaging, patching and so on myself. For several Linux versions like RedHat5 (32 and 64-bit), RedHat6, RedHat7, Suse Linux,
Oracle Linux, Solaris and Windows.

Kind regards
Norbert

This means you have a lot of free time.
This is not supposed to be done like that.

[GustavoVegas]

This is already May 2020, I am trying to install Zabbix 4.0 and the problem still prevails. It would seem like the most recent available packages are still holding this dependency. Interestingly enough, this is issue is not noted in the "Known Issues" section of the documentation (https://www.zabbix.com/documentation/4.0/manual/installation/known_issues).
What is a better alternative at this point? Is there a way one can install the RPM yet disable the functionality? Release 4.0 is supposed to be supported until October 31, 2023. I have been able to use 4.4, but with 5.0 out and 5.2 on the wings, it does not look like the best alternative. I would also need to automate the installations via Puppet, and the official modules are not up to spec for 5.0 yet. Please advise.

Thanks,
-- Gustavo Vegas.