Hello Robin,
Welcome to the list and thank you for working on this.
Generally I am very happy for you to take on Zabbix which needs some more love in IPFire.
But I am not sure what to make with all the custom tooling that comes in this patch series. It is a lot of code that might not be suitable for all users and probably would be hard work to extend (a few more details below).
Could you go more into detail why this is required? Doesn’t zabbix have any builtin tools to show running services?
Maybe it is a better idea to add a configuration template to the wiki (minus the code)?!
-Michael
On 7 Apr 2021, at 21:44, Robin Roevens robin.roevens@disroot.org wrote:
Since a new version of Zabbix Agent 5 LTS was released before the previous patch-set was reviewed, I resubmit my patchset as a V2 updating current zabbix_agentd 4.2.6 to 5.0.10 as opposed to v5.0.9 in my previous submission. The other 3 patches in the set remain unchanged.
For reference I'll include the summary again:
This set of patches does not only update the binaries (well, the first patch only does that) but also fixes some things that I see as problematic in previous version:
- /usr/lib/zabbix is created for users to drop custom agent
modules in, however that dir was removed and recreated on update as it was not in the backup. I added it to the backup and prevented deletion of the directory if it is not empty upon uninstall, so user-added content would not disapear when the package is removed.
- Sometimes a new version of the agent will introduce
new configuration parameters. In general the Zabbix Agent config file(s) should remain compatible, but we never know what the future will bring us; and the user may miss out on new features introduced with new parameters in the config file. However we don't want to plain overwrite the configfile as the user may (probably has) have changed it. Currently on upgrade configfiles are backed up, removed, new are installed, then overwritten by the old ones from the backup. Ending with the old config and the new agent. I didn't find an example of another package doing something similar, so I chose to save the new configfile(s) as .ipfirenew-files like RPM-based distro's do with .rpmnew-files. If the original config file is absent the install script will automatically strip the .ipfirenew extension. And if the new config file does not differ from the currently installed one, the .ipfirenew-file is removed. The install-script will also issue warning messages if such .ipfirenew-files are left on the filesystem, requesting the user to manually investigate and possibly merge the configfile. I hope those warnings are visible in the pakfire output. A side effect is that the config files are also not removed when the package is uninstalled. I don't see a problem here for the zabbix own config-files. But it may pose a risk concerning the sudoers-file?
- I added a few IPFire specific monitoring items to the agent
config which can be used for more in-depth monitoring of the IPFire installation. The user is of course free to use my template available on share.zabbix.com or github to monitor those items, or create their own template.
Thanks for considering this patch-set. Please be honest but gentle commenting on it :-).
Regards Robin
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.