Hi all

I have an Alpine container on Proxmox that we use as a Zabbix Proxy. On it there is a PHP script (no web server). When I ssh in with my normal user account and run the PHP from cli, it works great. When I su to user root (for testing) it works fine. But when I su to user zabbix, I get:
Class “PhpOffice\PhpSpreadsheet\Spreadsheet” not found

This a problem because it will be Zabbix that triggers the script once a day. I get the same error whether zabbix triggers the script, or I trigger it from cli.

I have other ash, php, and python scripts on the proxy that run just fine when Zabbix triggers them.

The require statements at the top of the script don’t throw an error:
require $folder . “/phpSpreadsheet/vendor/autoload.php”; use PhpOffice\PhpSpreadsheet\Spreadsheet; use PhpOffice\PhpSpreadsheet\Writer\Xlsx;

The error happens farther down when it creates a new spreadsheet in memory: $spreadsheet = new Spreadsheet();

I had to use Composer to install the phpSpreadsheet library. I was getting a bunch of file & folder permissions errors but I’m certain I’ve covered that as this is not a file permissions error. I even reran composer as the zabbix user to check for permissions.

From googling I’ve found that the zabbix user is a “service account” as opposed to a user account. I used “su zabbix -s /bin/ash” get a cli going so I could test running the script directly. Running env shows that the Zabbix user’s HOME directory is “/dev/null” Beyond that I’m not sure what differences there are between the accounts, or what would prevent a php class from loading.

Any help is welcome. Thanks.

  • Hexarei
    1·
    1 year ago

    It’s almost certainly a file permission error; Composer’s auto loader (the require statement) just scans the vendor library directories and populates the namespace, it doesn’t have a list to check answer l against and doesn’t load the classes up front. As such, if the file for a class isn’t accessible by the permissions, it will not be loaded into the namespace by the auto loader.

    PHP also doesn’t validate its usestatements, as they are basically just aliases that are resolved at the moment the import is used.

    Then, when it comes time to attempt to instantiate the class, PHP discovers there’s no class by that name and errors out.

    You just need to make sure the Zabbix user can access all the files in vendor, probably by deleting it and running the composer install as that user.