I found that example dummy module framework could be improved to allow speedup zabbix modules developers better manage own modules whole live cycle.
From new src/modules/dummy/README file:
This directory contains a sample dummy loadable module, which extends
functionality of the Zabbix Agent. The dummy.c module is well commented,
have a look at the sources to learn how to create Zabbix modules.
This tree also contains a template implementing all resources used on full
software package maintenance cycle of source code consisting from:
- building binary files on development stage
- final verification before release and package source tar ball
- building rpm package straight from source tar ball
- automatic embedding installed rpm package into configuration of the main
To build it you need to have the following rpm packages installed:
Description of steps necessary to:
- prepare source code tree build automation:
autoreconf --force --install
- compile module:
./configure <params>; make
make install [DESTDIR=<install_prefix>]
- generate clean tested distribution source tar ball:
- generate rpm packages (binary and source as well) from generated tar ball
rpmbuild -ta zbx_mod_dummy-<version>.tar.xz
- install generated package
rpm -Uvh zbx_mod_dummy-<version>-1.<arch>.rpm
If you want to publish generated package(s) into an rpm repository you need to
install the anaconda package which will provide zbx_mod_dummy package.
You need to create a directory to store the binary package and
afterwards to copy the rpm file into it you must update your repository indexes by:
It is good to create <repo_directory>/old directory and move after
release of the new package old binary packages to <repo_directory>/old
directory to hold in single repo current and older packages.
To upgrade package on systems which have registered in dnf/yum repo you
need to execute:
yum upgrade zbx_mod_dummy
dnf upgrade zbx_mod_dummy
As long as new and previous package will be in the same repository if anything will
be wrong with upgraded package availability as long as older binary package
is indexed by repository all what is really necessary to execute is:
yum downgrade zbx_mod_dummy
dnf downgrade zbx_mod_dummy
RPM package has registered LoadModule=zbx_mod_dummy.so configuration file
which will be installed in <sysconfdir>/zabbix_agentd.d directory. If
zabbix_agentd.conf file has uncommented line like:
this configuration file will be automatically added to agent configuration
so no manual operations will be needed to update agent setup.
Above template could be easily adapted to implement maintenance framework for zabbix
proxy/server loadable module.
Tomasz K?oczko <[email protected]>, Feb 2017
Makefile.am | 6
configure.ac | 3
include/Makefile.am | 54 ++
src/Makefile.am | 8
src/modules/dummy/COPYING | 674 ++++++++++++++++++++++++++++++++
src/modules/dummy/ChangeLog | 1
src/modules/dummy/INSTALL | 370 +++++++++++++++++
src/modules/dummy/Makefile | 2
src/modules/dummy/Makefile.am | 21
src/modules/dummy/NEWS | 2
src/modules/dummy/README | 96 ++++
src/modules/dummy/configure.ac | 48 ++
src/modules/dummy/zbx_mod_dummy.spec.in | 49 ++
zabbix-1.0.pc.in | 17
14 files changed, 1337 insertions(+), 14 deletions(-)
As it is possible to see main part of the patch is just add copy of COPYING and INSTALL file which is added by automake so effectively whole patch contains very small set of changes.
IMO this patch is still in VIP state because man set of modifications must be done on carefully selecting zabbix herer files which will define set of types, structures etc which will be first version of official zabbix module API 1.0 interface. What is in the patch contains only changes to allow pack and build standalone zabbix dummy module.
I know that other publically available loadable modules are using much more header file. Problem is that those header files contains sometimes definition which are not relevant to modules API interface. As consequence IMO it would be good to spend some time on reorganizing include/ content to separate *.h files with only those definition which can be used on modules development. With those changes some minor updates in rest of the zabbix tree needs to be added as well.
Attached patch can applied against 3.0, 3.2 and trunk trees.
PS. If generally this patch will be approved by zabbix dev team as something which is worth spend more work on it I will try to publish information about this ticket on "Zabbix Patches" forum to attract other zabbix modules developers to finish this part.