Zabbix ships its PHP web UI application(s) as the zabbix-web and zabbix-frontend-php packages, for RPM and Debian package manager based systems respectively. Both of these packages install the PHP application files under /usr/share/zabbix.

Both Red Hat Enterprise Linux (and derivatives or clones, such as SUSE Linux, Oracle Linux, Rocky Linux, Alma Linux, etc.) and Debian (and derivatives, such as Ubuntu and Raspberry Pi OS) implement the Filesystem Hierarchy Standard. RHEL does not explicitly state the version of the standard it complies with.^[1][2]

The standard describes the /usr/share directory as used for all read-only architecture independent data files. This directory should contain files, subsystem specific directories, or application specific directories, with data files used by the respective applications. Commonly, application packages use this directory to store images, static databases, default configurations, and auxiliary source code files that can be sourced by the main application (as an example, shells do this, to provide optional functionality additions).

As systems conforming to FHS are allowed to expect the /usr directory to be read-only, the current web UI application package violates this expectation, as the UI setup wizard writes the configuration file to the conf sub-directory of the application root directory. As a result of this, the current directory choice is incorrect in regards to compliance with FHS.

Additionally, Zabbix provides two packages, zabbix-apache-conf and zabbix-nginx-conf, containing configuration for the Apache and Nginx web servers respectively.

These configurations set the /usr/share/zabbix directory to be served by the web server and describe rules allowing and/or denying requests for files and directories in this tree. Thus, using this directory to store actual static Zabbix related data becomes inappropriate, as access to them, if not covered by rules in these configuration files, depends on the global configuration of the web server, which Zabbix is not in control of. This effectively prevents using the directory for other purposes. An example would be providing the optional database patches, which, due to the current use of the directory, have been split out into a separate /usr/share/zabbix-sql-scripts directory.

The two web servers, Apache and Nginx, default to setting their document root directories to /var/www/html and /usr/share/nginx/html respectively.

In both cases, these directories hold the default, static HTML documents for common requests that are not over-ridden by other rules or do not route to valid virtual hosts and/or documents (such as the default index.html page, 404.html, 50x.html, and related assets).

The suggestion is to move the configuration file into the zabbix system configuration directory, /etc/zabbix, and move the PHP application files to a nested directory, /usr/share/zabbix/cgi-bin or equivalent, to allow the /usr/share/zabbix directory to be used for additional purposes.

This will, however, prevent the setup wizard from writing the configuration file.

if we wish to maintain this behavior, the application files should be moved to a directory known to be writable by the web server process user.

During the installation of Zabbix server, proxy and/or agent packages, the post-install hook creates a dedicated user, and sets its home directory, usually to /var/lib/zabbix, which is always be writable, as the entire /var tree is intended for writable data. This directory does not get created, as in the RPM case, the hook creates a system user, and in the case of Debian, the hook explicitly passes --no-create-home to adduser.

However, as the /var hierarchy in general is intended for variable data (such as mail spools, logs and socket files), this isn't an appropriate location either.

Another option would be to actually create a dedicated user directory under /home, which should be writable, but is optional, according to the FHS, and could still cause problems if not set up correctly, such as not being readable by the user running the web server or FPM processes.

In general, having the UI write its configuration to the file system seems inappropriate, and maybe should be reconsidered.

^[1]: RHEL: https://access.redhat.com/articles/rhel8-abi-compatibility
^[2]: Debian: https://wiki.debian.org/FilesystemHierarchyStandard