Re: Packaging different Zabbix agent versions

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

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

Hello Robin,

This is an interesting question to which I don’t have a very good answer.

> On 26 Oct 2024, at 23:08, Robin Roevens <robin.roevens(a)disroot.org> wrote:
> 
> Hi all
> 
> I would like to start releasing packages for Zabbix Agent 7.0 (new LTS)
> as it offers some added value when used with Zabbix server 7.0
> (heartbeat, item-level custom timeouts, ...).
> However, the agent is not backwards compatible. Hence, if I would
> update the zabbix_agentd package to contain v7.0, people still running
> Zabbix 6.0 LTS (still supported until feb. 2027) or even 6.2 or 6.4
> would then no longer be able to monitor IPFire.

I consider this quite bad software design since it is causing some issues with their user base and creates a lot more work for distributions to package two of the same software. We also ready have a lot of different monitoring tools and occasionally people request more, so I assume that each of them have already only a small user base as they divide the market - and now having two versions of Zabbix is even further splitting the Zabbix user base so that I am sure that for each version we will only have very few users, but still a lot of work to package it.

This is just for the record. It would be nicer if upstream would give us better migration paths.

> So it would be nice if we could provide both zabbix_agentd 6.0 and 7.0
> packages so users can choose depending on their Zabbix server version.
> I think offering different versions of the same software is not yet
> done before?

Luckily this was not necessary, or in case of Icinga/Nagios there was a fork that renamed the package so that there were no file conflicts.

Pakfire in IPFire 2 was never supposed to be a full-blown package management system and therefore it does not support conflicts like Pakfire in IPFire 3 does. There, we would simply configure that those packages cannot be installed at the same time and the package management system will take care of it.

> How should I do this? Just add a new package zabbix_agentd7 next to the
> current zabbix_agentd package?

There is a way… but before, maybe it is worth to conduct a little survey on community.ipfire.org <http://community.ipfire.org/> to see if there are actually any users who have a preference either way? I don’t know much about Zabbix so I am not sure how fast people are with upgrading (I assume a single device in your infrastructure that does not support version 7 will block you from moving everything forward?).

> But if so:
> - Can we then rename the zabbix_agentd pak to zabbix_agentd6 (I don't
> immediately see how that should be handeled during upgrade?).
> If not possible or feasable, that's not that big of a deal as in time
> (feb 2027) that package can be removed and that "problem" then has
> solved itself. So this is maybe just some unneeded hassle.

We could rename it, that might make the whole thing a little bit cleaner.

Either you can add the major release number or simply call it zabbix-agent-legacy? Whatever you fell is most appropriate.

This change would have to be done in the core update though.

> - Can we prevent users from installing both packages as they will
> conflict? (both file-wise and used port-wise)

Hmm, that will be a problem. Pakfire does not support conflicts. We can either add this (because to simply conflict with a name this might not be too hard to do), or another version would be to actually build everything in such a way that there are no real conflicts. Rename /usr/sbin/zabbix_agentd to /usr/sbin/zabbix_agentd-7 and so on.

There are install scripts that we have used before to stop the installation process, but those are being called *after* the files have been extracted so the formerly installed version will already have been overwritten.

> - And what should I do with the IPFire specific customizations as they
> will be identical for both packages.:
>  - Just duplicate them to both packages, (probably the easiest)
>  - or move them to yet another package

Good question. It might be easiest to just copy things. Because then we can just drop the older version whenever time is right and don’t have to merge packages together again. I hope this break is a one-off and version 8 won’t do this again.

> "zabbix_agentd_ipfire_extension".. And then let both agent packages
> depend on that one. But that may be confusing to the user as that
> package would require one of the then 2 zabbix_agentd packages to be of
> any use, but we can't do a zabbix_agentd OR zabbix_agentd7 dependency,
> I think?

I would not be against it if you prefer this option. Technically it will work.

> ...
> 
> Or should we just refrain from adding v7.0 for now.. and then probably
> until 2027 or until ipfire3, (if pakfire there supports such packages
> conflict/dependency mechanisms?).. but by then there probably is
> already an 8.0 and possibly a 9.0..

Good question, maybe this is worth to investigate with the community if there is demand for version 7 already. I don’t know how fast people will upgrade. Having said my thoughts from earlier, IPFire should not be the blocker why people cannot upgrade their entire infrastructure to version 7.

Is there any reason that justifies this big break?

-Michael

> So...
> 
> I would like your thoughts about this ?
> 
> Robin