News draft: zabbix >= 7.4.1-2 may requires manual intervention
Hi, I've been working on a significant rework of the zabbix split package [1] over the past few days, introducing a fair amount of changes and improvements. One key change consists of replacing the multiple sysusers historically created for each zabbix components with a single shared "zabbix" user: - It aligns better with the intended upstream standard and the way other distributions does this (see [2] for more details). - The previous historical approach was somewhat *hacky*, e.g. relying on unnecessarily static UID:GID for each user and running some `chown` during `package()` rather than relying on systemd sysusers.d / tmpfiles.d. That said, this change *may* require manual intervention from users. While I'm aware that Zabbix component usage on Arch Linux might be relatively low, I believe that monitoring components are critical enough to warrant a news entry about this change and the potential impact it implies. Of course, feel free to let me know if you think otherwise. News draft below. Pad available at [3]. ---------- # zabbix >= 7.4.1-2 may requires manual intervention Starting withi `7.4.1-2`, the following Zabbix system users (previously shipped by their related packages) will no longer be used. Instead, all Zabbix components will now rely on a shared `zabbix` user (as originally [intended by upstream](https://www.zabbix.com/documentation/current/en/manual/installation/install#...) and done by other distributions): - zabbix-server - zabbix-proxy - zabbix-agent *(also used by the `zabbix-agent2` package)* - zabbix-web-service This shared `zabbix` user is provided by the newly introduced `zabbix-common` *split* package, which is a now a dependency for all relevant `zabbix-*` packages. The switch to the new user is handled automatically in the corresponding `systemd` service units. However, **manual intervention may be required** if you have custom files or configurations referencing / being owned by the above deprecated users, for example: - `PSK` files used for encrypted communication - Custom scripts for metrics collections / report generations - `sudoers` rules to metrics requiring elevated privileges to be collected - ... Those should therefore be updated to refer to / be owned by the new `zabbix` user, otherwise some services may fail to start properly (if not at all). Once migrated, you may optionally remove the obsolete users and their primary groups from your system (see the [related Arch Wiki page](https://wiki.archlinux.org/title/Users_and_groups) for details). ---------- [1] https://gitlab.archlinux.org/archlinux/packaging/packages/zabbix [2] https://gitlab.archlinux.org/archlinux/packaging/packages/zabbix/-/issues/12... [3] https://md.archlinux.org/YjsLnkzRRoeMa7BP3gxYKw# -- Regards, Robin Candau / Antiz
On 2025-08-03 14:09:41 (+0200), Robin Candau wrote:
Hi,
I've been working on a significant rework of the zabbix split package [1] over the past few days, introducing a fair amount of changes and improvements.
One key change consists of replacing the multiple sysusers historically created for each zabbix components with a single shared "zabbix" user:
- It aligns better with the intended upstream standard and the way other distributions does this (see [2] for more details).
- The previous historical approach was somewhat *hacky*, e.g. relying on unnecessarily static UID:GID for each user and running some `chown` during `package()` rather than relying on systemd sysusers.d / tmpfiles.d.
That said, this change *may* require manual intervention from users.
While I'm aware that Zabbix component usage on Arch Linux might be relatively low, I believe that monitoring components are critical enough to warrant a news entry about this change and the potential impact it implies. Of course, feel free to let me know if you think otherwise.
News draft below. Pad available at [3].
Kudos for cleaning this up! I've fixed a few typos in the pad, but otherwise this looks fine to me. Somewhat related to your change, I think it would also be good to not run the PHP frontend as the http user [a], as the webserver runs as that. With nextcloud and other web applications we have also switched to separate users, but as this may require a bit more setup and change party, it's probably better to do this in a follow-up. Best, David [a] https://gitlab.archlinux.org/archlinux/packaging/packages/zabbix/-/blob/35e4... -- https://sleepmap.de
On 8/3/25 10:14 PM, David Runge wrote:
On 2025-08-03 14:09:41 (+0200), Robin Candau wrote:
Hi,
I've been working on a significant rework of the zabbix split package [1] over the past few days, introducing a fair amount of changes and improvements.
One key change consists of replacing the multiple sysusers historically created for each zabbix components with a single shared "zabbix" user:
- It aligns better with the intended upstream standard and the way other distributions does this (see [2] for more details).
- The previous historical approach was somewhat *hacky*, e.g. relying on unnecessarily static UID:GID for each user and running some `chown` during `package()` rather than relying on systemd sysusers.d / tmpfiles.d.
That said, this change *may* require manual intervention from users.
While I'm aware that Zabbix component usage on Arch Linux might be relatively low, I believe that monitoring components are critical enough to warrant a news entry about this change and the potential impact it implies. Of course, feel free to let me know if you think otherwise.
News draft below. Pad available at [3].
Kudos for cleaning this up!
Thanks :)
I've fixed a few typos in the pad, but otherwise this looks fine to me.
Thanks again :)
Somewhat related to your change, I think it would also be good to not run the PHP frontend as the http user [a], as the webserver runs as that.
With nextcloud and other web applications we have also switched to separate users, but as this may require a bit more setup and change party, it's probably better to do this in a follow-up.
Sure, I can take a look at that. Are their any expected impact for users regarding this transition? If so, maybe it should be shipped at the same time as the above change to group impactful changes in a single batch (while we are in the process of sending a news for it)?
Best, David
[a] https://gitlab.archlinux.org/archlinux/packaging/packages/zabbix/-/blob/35e4...
-- Regards, Robin Candau / Antiz
On 2025-08-04 09:17:21 (+0200), Robin Candau wrote:
Somewhat related to your change, I think it would also be good to not run the PHP frontend as the http user [a], as the webserver runs as that.
With nextcloud and other web applications we have also switched to separate users, but as this may require a bit more setup and change party, it's probably better to do this in a follow-up.
Sure, I can take a look at that.
Are their any expected impact for users regarding this transition? If so, maybe it should be shipped at the same time as the above change to group impactful changes in a single batch (while we are in the process of sending a news for it)?
This usually means that a dedicated php-fpm or uwsgi config (or whatever people are using) needs to be created/adapted. For ease of integration, we have added a configuration for uwsgi in the nextcloud package, but not yet for php-fpm. Here, the custom ownership is also specifically limited to /etc, and everything below /usr remains root owned (with symlinks to e.g. cache or config directories). Some applications don't even need full ownership over their configuration files, as they only require read access (but that is really application-specific). FWIW, in this context it is questionable whether you would want to use the same system user (zabbix) for the PHP based frontend, too. I hope this helps somewhat to gain an overview. Best, David -- https://sleepmap.de
On 8/4/25 10:49 AM, David Runge wrote:
On 2025-08-04 09:17:21 (+0200), Robin Candau wrote:
Somewhat related to your change, I think it would also be good to not run the PHP frontend as the http user [a], as the webserver runs as that.
With nextcloud and other web applications we have also switched to separate users, but as this may require a bit more setup and change party, it's probably better to do this in a follow-up.
Sure, I can take a look at that.
Are their any expected impact for users regarding this transition? If so, maybe it should be shipped at the same time as the above change to group impactful changes in a single batch (while we are in the process of sending a news for it)?
This usually means that a dedicated php-fpm or uwsgi config (or whatever people are using) needs to be created/adapted.
For ease of integration, we have added a configuration for uwsgi in the nextcloud package, but not yet for php-fpm. Here, the custom ownership is also specifically limited to /etc, and everything below /usr remains root owned (with symlinks to e.g. cache or config directories). Some applications don't even need full ownership over their configuration files, as they only require read access (but that is really application-specific).
FWIW, in this context it is questionable whether you would want to use the same system user (zabbix) for the PHP based frontend, too.
I hope this helps somewhat to gain an overview.
Best, David
Alright, thanks a lot for the pointers! As discussed together, the required changes are not trivial and require quite some testing. That doesn't feel like something I'll be able to work on in a timely manner right now, in case I wanted to add this to the current batch of changes. So I'll keep it for a follow-up indeed! I may ping you for some questions / help when I start working on it though (if that's alright). Thanks again for sharing some thoughts :) -- Regards, Robin Candau / Antiz
participants (2)
-
David Runge
-
Robin Candau