Re: [PATCH 0/4] [V2] zabbix_agentd: new maintainer/summary

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 3659 bytes --]

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(a)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.
>