Since Zabbix is making use of libxml2 already, that may be a candidate.

iksemel also fails to build with gnutls 3.4.4 and up, it seems.

Maybe you could get rid of it at all. I did a quick research and it's not like there are a lot of C XMPP libraries that are maintained or have a suitable license. With TLS support in place, an additional effect is, that you are potentially dragging in two different TLS libraries (gnutls + openssl or .mbed).

The latest code in https://github.com/meduketto/iksemel claims to support openssl as an alternative to gnutls, and it does at least compile with the current openssl in Fedora Rawhide, so that might be a candidate. But the code is still very old and unmaintained.

Also iksemel has very unsecure hardcoded TLS settings, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803204
It was reported without any action so far: https://github.com/meduketto/iksemel/issues/48
So we should get away from this library as soon as possible.

Iksemel doesn't compile with OpenSSL 1.1.0. So...

BUMP

tlv1 is deprecated in ejabberd 17.08 by default so we need to turn it on manually to make it work with zabbix. Please resolve the issue to prevent jabber notifications from being completely broken.

Sorry for misinformation. zabbix is completely uncompatible with ejabberd > 16.09. Can't make them work together.

Currently we provide package iksemel for RHEL/CentOS in our repository (zabbix-non-supported). If you install package zabbix-release you will get access to it:

# rpm -q zabbix-release
zabbix-release-4.0-1.el7.noarch

# cat /etc/redhat-release 
CentOS Linux release 7.5.1804 (Core) 

# yum list iksemel
[...]
iksemel.x86_64 1.4-2.el7.centos @zabbix-non-supported

I agree this is not the best solution and we should get rid of dependency on that library, but rewriting the code would definitely require few weeks of coding.

Dimir, thank you for the info. You are right, the provided steps are very useful and it actually works if the setup has direct access to the Internet. 

The reason for this to be brought up was an unfortunate setup with no direct access to Zabbix repo and with only the 4.0 repo synced for RHEL locally, not including zabbix-non-supported thus blocking the installation of Zabbix server. Probably a very narrow use case but still. 

Anyways, thumbs up and I hope you will get this resolved properly by removing the dependency with the code. 

https://bugzilla.redhat.com/show_bug.cgi?id=1594986#c4 for the reference.

Thank you, ingus.vilnis! Yes, this is interesting.

How about mirroring zabbix repo at your premises aside of RedHat ones? After all, I do not see how you get zabbix packages without internet, but if you do, why not pick iksemel as well?

Anyway, I notified our decision makers about the issue. Looks like at this very moment we lack resources on fixing it. But, if your company is interested in sponsoring the development to get rid of iksemel dependency, [email protected] would be happy to know about it.

The repo is mirrored locally but apparently only this folder. http://repo.zabbix.com/zabbix/4.0/rhel/7/x86_64/ Unfortunately I got no control over this. It probably would be possible to add also iksemel there but it is a complex procedure. Sure, those are internal specifics, not a fault of official packaging because technically the iksemel is in your repo. 

As said, for the particular setup we found a way to get everything done just by copying the package locally from another server and Zabbix 4.0 is happily running. 

Good to know. Happy monitoring!

I think instead of re-implementing support for Jabber using libxml it would be wiser to replace support for Jabber with support for nowadays popular Telegram. This way we would get rid of dependency on obsoleted library + happy users that want to get notifications over Telegram.

Imho it's bad idea to replace xmpp with telegram. xmpp is fully opensource and decentralized protocol, so anybody can make it's own jabber server. And telegram uses proprietary servers. Also telegram is blocked in Russia so (because of centralized servers) it can be problem using it here.

By the way I have mailed to [email protected] abount sponsoring xmpp development for the zabbix, but got no respond for more then a week.

I will discuss with our c++ developer whether he can make this work and provide a patch here.

Thanks, I'll ping them.

On the Telegram topic, much work was done by this guy: https://github.com/ableev/Zabbix-in-Telegram

Another idea is making our alert system modular. Each messenger module provides additional media type, that way adding/removing support for specific messenger would be much easier.

I also have made xmpp notification using "external script alerts" option in zabbix and python script https://raw.githubusercontent.com/jabber-at/python-nbxmpp/master/doc/examples/xsend.py

JFYI, I've got an anser from sales team:

"after the detailed discussion of the specifications provided we have to inform you that the requested development works cannot be delivered and external patches could not be accepted."

I think ZBXNEXT-2902 is the way to go.