Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 9, Debian 10, Debian 11, Debian 12

Summarizing:

• Zabbix PHP web UI applications are distributed via zabbix-web and zabbix-frontend-php packages for RPM and Debian systems respectively, installing under /usr/share/zabbix.
• FHS expects /usr/share to hold read-only, architecture-independent data, but Zabbix setup violates this by writing to this directory.
• zabbix-apache-conf and zabbix-nginx-conf packages configure web servers to serve from /usr/share/zabbix, limiting its use for static data due to potential access control issues.
• The Apache and Nginx servers default document roots are /var/www/html and /usr/share/nginx/html, intended for static HTML documents.
• Suggestions include moving the configuration file to /etc/zabbix and PHP application files to a subdirectory within /usr/share/zabbix to maintain FHS compliance and enhance directory usage flexibility. This, however, could make the setup wizard's functionality more difficult.

Conclusion: The deployment of Zabbix Front End challenges FHS compliance due to its writing operation in a supposed read-only directory and complicates the efficient use of web server configurations. 

Fair point as FHS_3.0 states it nice and clear:

The /usr/share hierarchy is for all read-only architecture independent data files. [30]

This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted. Note, however, that /usr/share is generally not intended to be shared by different OSes or by different releases of the same OS.

Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally). It is recommended that a subdirectory be used in /usr/share for this purpose. Applications using a single file may use /usr/share/misc.

Game data stored in /usr/share/games must be purely static data. Any modifiable files, such as score files, game play logs, and so forth, should be placed in /var/games.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html#ftn.idm236091847456

On the other hand, the FHS provides guidelines for filesystem structure with the aim of standardization and compatibility. However, practical exceptions are sometimes necessary to accommodate specific application requirements or to enhance user experience. If current structure serves its user base effectively, deviating from FHS guidelines in this case could be justified. Current setup, where Zabbix PHP application files reside in /usr/share/zabbix, is a practice that has been in place for years. It offers operational continuity for users and administrators familiar with the existing structure. Changing this could introduce confusion.

Hey, mkudlacz.

I disagree with the last portion of your comment, because that room for deviation or exceptions is given to the system engineers who define the system policy (i.e. Red Hat Enterprise Linux and Debian maintainers, in this case), not arbitrary applications (i.e. Zabbix). This would be the case if any of the LSB components, or additional applications from the distribution maintainers, would behave in this manner as part of the base system install, but they do not on any system that advertises LSB or FHS compliance.

I also disagree with the argument along the lines of "well, we've always done it this way", as what it reads as is "we've always done it wrong and will continue doing so". Nor with the assertion that this would "introduce confusion", as this just sounds like we consider users to be inept. Maintaining this behavior, because the "users may get confused", at the expense of those users that want to run standards compliant systems and make full use of them, would be odd to say the least.

The current behavior actually prevents me from running disk-less systems, as due to the configuration file residing where it does, multiple hosts can no longer share a single, read-only /usr mount.

Hi Juris,

Please don't get me wrong. I fully support your statements and agree that adherence to standards and best practices is crucial for system compatibility and maintenance. My intention in presenting the other perspective was not to dispute this importance but to acknowledge that there are complex factors at play. These factors include the practical implications of changes for existing users and systems.

Confirming and moving to Development.

All good, mkudlacz! I didn't mean to come off as contrarian.

I think that we should address this in packages as soon as we feasibly can, and maybe for 7.0 consider getting rid of the wizard writing portion altogether (instead maybe displaying the configuration with instructions on how to install it, and still providing the option of downloading it as a file).

I get that there are a bunch of factors in play here, but correcting wrongs is always a bit painful, and this would be a noticeable change. At the same time, keeping these warts around just out of comfort isn't a great idea either, and I think a major version release is the correct time for that change, as with all other major behavior overhauls.

Frontend part fixed in pre-7.0.0rc3

• Frontend files moved from /usr/share/zabbix to /usr/share/zabbix/ui
• Removed symlink to zabbix.conf.php file in /etc/zabbix/web on DEB-based systems. Patching the frontend code to write configuration directly to /etc/zabbix/web/ directory, like it is already done on RPM-based systems.

Upgrade from earlier versions results with 403 Forbidden or page not found.

Paths remain unchanged in /etc/nginx/conf.d/zabbix.conf

               root    /usr/share/zabbix;

               fastcgi_param   DOCUMENT_ROOT   /usr/share/zabbix;
               fastcgi_param   SCRIPT_FILENAME /usr/share/zabbix$fastcgi_script_name;
               fastcgi_param   PATH_TRANSLATED /usr/share/zabbix$fastcgi_script_name;

Correcting paths and restarting nginx and php-fpm resolves the issue. I believe the same is applicable for apache / httpd.

I presume, that the configuration was not overwritten during upgrade, as it should, mkudlacz.
This is standard behavior of package managers to preserve configuration files with user edits.

The user should install the new file, and the reconfigure the necessary settings. Hence we are only doing this change for a major 7.0 release.

The package is in fact correct.

packager@builds:~/pkg/deb$ ar x zabbix-nginx-conf_7.0.0~rc3-1+debian12_all.deb
packager@builds:~/pkg/deb$ tar xvf data.tar.xz
./
./etc/
./etc/zabbix/
./etc/zabbix/nginx.conf
./etc/zabbix/php-fpm.conf
./usr/
./usr/share/
./usr/share/doc/
./usr/share/doc/zabbix-nginx-conf/
./usr/share/doc/zabbix-nginx-conf/changelog.Debian.gz
./usr/share/doc/zabbix-nginx-conf/changelog.gz
./usr/share/doc/zabbix-nginx-conf/copyright
packager@builds:~/pkg/deb$ grep -n /usr/share/zabbix ./etc/zabbix/nginx.conf
5:        root    /usr/share/zabbix/ui;
41:                fastcgi_param   DOCUMENT_ROOT   /usr/share/zabbix/ui;
42:                fastcgi_param   SCRIPT_FILENAME /usr/share/zabbix/ui$fastcgi_script_name;
43:                fastcgi_param   PATH_TRANSLATED /usr/share/zabbix/ui$fastcgi_script_name;

Tips for upgrading from earlier versions < 7.0

This should only affect nginx users, unless you edited /etc/httpd/conf.d/zabbix.conf file, which is not normally needed.

RedHat and SUSE:

You will get the following message when running dnf update.

  Upgrading        : zabbix-nginx-conf-7.0.0-release1.el8.noarch               4/16
warning: /etc/nginx/conf.d/zabbix.conf created as /etc/nginx/conf.d/zabbix.conf.rpmnew

Backup the /etc/zabbix/nginx.conf file.

cp /etc/zabbix/nginx.conf /etc/zabbix/nginx.conf.bak

Replace the old configuration file with the new one.

cp /etc/nginx/conf.d/zabbix.conf.rpmnew /etc/nginx/conf.d/zabbix.conf

Then edit the file and restore your old configuration.

Debian / Ubuntu / Raspberry Pi OS:

Backup the /etc/zabbix/nginx.conf file.

cp /etc/zabbix/nginx.conf /etc/zabbix/nginx.conf.bak

You will get the following message when running apt upgrade command.

Configuration file '/etc/zabbix/nginx.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** nginx.conf (Y/I/N/O/D/Z) [default=N] ?

Select the Y or I option to install the updated file. Then edit the /etc/zabbix/nginx.conf to restore whatever configuration you had there.

After consulting with alexei, we decided to revert the change for 7.0.0 stable release.

Available in 7.2.0alpha1

NOTE: I ended up not removing conf file symlink on debian. So in 7.2 it works the same way as in earlier versions.

Released 7.2.0alpha1-2 packages for all deb systems with a fix for the symlink location 5708624615b

Updated documentation:

• Upgrade notes: 7.2