-
Incident report
-
Resolution: Unresolved
-
Trivial
-
None
-
3.0.8rc1, 3.2.3, 3.4.0alpha1
-
None
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 Zabbix packages To build it you need to have the following rpm packages installed: - autoconf - automake - gcc - glibc-devel - pkgconfig - rpm-build - xz - zabbix-devel Description of steps necessary to: - prepare source code tree build automation: autoreconf --force --install - compile module: ./configure <params>; make - install: make install [DESTDIR=<install_prefix>] - generate clean tested distribution source tar ball: make distcheck - 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: createrepo <repo_directory> 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 or: 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 or: 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: Include=<sysconfdir>/zabbix_agentd.d 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. kloczek -- Tomasz K?oczko <[email protected]>, Feb 2017
diffstat output:
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.