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-web-mysql — Frontend fitting a server implementation
- zabbix20-proxy-mysql — A proxy implementation
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.