EPEL finally offers Zabbix 2.0 packages. These packages are for you, if you are running RHEL, CentOS, Scientific Linux or any other Red Hat derivative. EPEL aims to provide best quality packages, that follow the same rules and conventions as Red Hat packages and therefore integrate smoothly.
If you know what EPEL is, keep on reading. If not, first skip over to “What is EPEL and why would I use this repository?” below.
Notice: At the time of writing, packages are only available for version 6. Packages for 5 are in the making.
- Update, 22 Jan 2013: EPEL 5 packages are in the testing phase now
- Update, 11 Feb 2013: EPEL 5 packages are available
In a nutshell
- zabbix20 — Base package; Contains zabbix_sender and zabbix_get
- zabbix20-agent — Contains zabbix_agent, zabbix_agentd
- zabbix20-server-mysql — A server implementation
- zabbix20-server-pgsql
- zabbix20-web-mysql — Frontend fitting a server implementation
- zabbix20-web-pgsql
- zabbix20-proxy-mysql — A proxy implementation
- zabbix20-proxy-pgsql
- zabbix20-proxy-sqlite3
Installing Zabbix 2.0 is easy:
- Enable the EPEL repository
yum install <zabbix20-stuff-you-need>
If you’re using Red Hat Network (RHN), you may also require the channel “RHEL Server Optional”, depending on what you’re installing.
Where available, newer versions can be installed:
yum --enablerepo=epel-testing install <zabbix20-stuff-you-need>
If you install from testing, please leave feedback as a registered user for the exact version you installed. This helps getting updates to users more quickly.
zabbix20 packages will not install in parallel with zabbix packages; you must remove them before. You will not lose your configuration files if the zabbix packages came from EPEL, nor will you loose your database. Packages from other sources may behave different.
What is EPEL and why would I use this repository?
You might have encountered other sources of 2.0 packages. Why would you pick EPEL?
EPEL is a well known source of packages for RHEL (Red Hat Enterprise Linux) and its derivatives. Most probably you’re using it already, as it provides fping and libiksemel, used in Zabbix for ICMP echo requests and sending notifications via Jabber (XMPP), respectively. EPEL is not part of Red Hat. EPEL packages are maintained by Fedora packagers. EPEL packages follow the same packaging rules as packages in RHEL. They therefore aim to be the best fitting you can get. If you’re interested in details, please read my more in-depth essay, why picking distribution packages is a good idea and a little list of reasons, why using packaged software is useful in general.
The Zabbix 2.0 package is called zabbix20 instead of zabbix, due to EPEL’s stable policy. Updating to 2.0 is a major step. If the same name was used, 2.0 would just appear as an update to 1.8, which we’re trying to avoid. You also can’t install zabbix and zabbix20 in parallel, because files would clash. If you need them on the same physical machine for testing, consider setting up a chroot.
EPEL has a policy of keeping updates in a testing repository for 14 days. Please test and leave feedback as a registered user, if you install from testing. With enough positive feedback, the incubation period can be vastly shortened, i. e. updates arrive on production sites earlier.
The EPEL package deviates from packages of other distributions as well as from what you get, when you just “make install” Zabbix. The differences are listed in a file called zabbix-fedora.README, which is part of the base package. Some of the more remarkable ones are:
- Different users for agent and server/proxy
- Media scripts and external scripts sub-directory are set up in the server user’s home directory
- Use of the Alternatives system to switch between database implementations
- No SQLite front-end, because it doesn’t work in EL
- No Java gateway — Feel free to vote on the ticket!
Bugs of EPEL packages are tracked on bugzilla.redhat.com. If you encounter problems, please try to contact me via that tracker, on Freenode IRC (volter) or volker27[at]gmx.at.
Just in case you wonder, Fedora has no “zabbix20” packages. Version 2.0 will be available as “zabbix” from Fedora 18 on.
Volker, thanks for this nice article !
I have just a small note – I’d explicitly mention that server/proxy will use “zabbixsrv” user name for running as a daemon. And add info that this is handled in init scripts.
I was just wondering which user name you have selected and I was forced to download and take a look to packages 🙂
EPEL 5 builds will be available via epel-testing within the next few days. Please test and leave feedback as registered users!
https://admin.fedoraproject.org/updates/zabbix20-2.0.4-4.el5
EPEL 5 builds are available now!
I read about the upcoming 2.2 release of zabbix and that 2.2-beta1 phase started a couple days ago. Are there beta1 rpms available? (Yes, I already scanned the web.)
hmm. where did it say that beta1 phase has started ? 🙂
No, at least not from my side. I’ll wait for a Beta tarball before doing anything.
Are 2.0.7 packages coming to EPEL? Is there any estimate?
Thanks.
2.0.7 had 2 or 3 issues that made me delay the update. Now that 2.0.8 is almost around, I’ll probably skip it.
Thanks for the info!
Hi,
Any news about 2.0.8 packages?
They are in epel-testing for both EL5 and 6. I won’t announce them here every time. It’s best to either run
yum –enablerepo=epel-testing update zabbix20
or check https://admin.fedoraproject.org/updates from time to time.
Please give feedback on new builds, as described in the article above.
Thanks for the info. I have missed the testing repo…
stratos, wanna test this build? One more vote and we’re good.
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11737/zabbix20-2.0.8-3.el6
Done!
Hello!
Are 2.2 packages in the plans or not? If there are, do we have a safe upgrade path?
Thanks!
Yes, certainly.
The upgrade will involve removing zabbix20 packages, just like you had to remove zabbix packages for zabbix20. As zabbix22 is considered a new package to EPEL, we have to go through a formal package review process. I’m preparing drafts for this review at the moment. EPEL 5 is a bit tricky because of the requirement on PHP 5.3. RHEL provides php53 packages, so it’s going to work there too.
I’m greatly looking forward to your help again, as soon as the formal review is done and we’re entering the same cycles as with zabbix20 before.
If you’re curious, you can try the packages from http://www.geofrogger.net/review/z22/ (see the README!)
They pretty much resemble the zabbix20 packages forked off from 2.0.6, thus don’t have improvements done after that. EPEL packages will differ, but not substantially. I’m trying to create them in a way that allows an upgrade from the Geofrogger packages, but no warranty!
I upgraded zabbix20s with the Geofrogger packages and that went well and easy (Partitioned PG setup, frontend and agent)
I think I’ll wait for the formal procedure through EPEL, then I’m going to have questions because it will be my first upgrade (I started with a clean 2.0, not upgrade from 1.8).
To start, is a db backup (I use postgresql) enough to restore in case of problem?
That should suffice, yes. The configuration files are backed up by RPM.
Thanks. Looking forward for any news and the testing release of the packages.
CVE-2013-6824 fixed in 2.0.9-2 and 1.8.18-2. Please test and leave feedback on the Fedora update system; see earlier comment!
zabbix22 went on package review for EL6 yesterday. The EL5 version will follow within days or weeks. I intend to keep the naming scheme through EL7 to reduce confusion about which version the package “zabbix” actually contains.
https://bugzilla.redhat.com/show_bug.cgi?id=1048621
It’s also worth noticing that “zabbix” (1.4.7) was finally removed from EPEL5, as there are known vulnerabilities and there’s no further support.
zabbix22 passed the review and is now in epel-testing for EL6. Please test and leave karma as registered users to bring it to the stable repository faster. EL5 and 7 should follow shortly.
https://admin.fedoraproject.org/updates/zabbix22-2.2.1-5.el6