Skip to content

Arch Linux httpd/apache with php and the issue that php-cli can write to /usr/share/webapps but php-http (php-fpm) can not

I wanted to install dolibarr on my arch linux machine.

The first steps are simple and I tried to stick to the official but little outdated aur package.

#as root
cd /usr/share/webapps
mkdir dolibarr
cd dolibarr
git clone https://github.com/dolibarr/dolibarr -b 14.0.1 .
cd ..
choown -R http:http dolibarr
sudo -u http touch dolibarr/htdocs/conf/conf.php

cat > /etc/httpd/conf/extra/httpd-dolibarr.conf <<DELIM
Alias /dolibarr "/usr/share/webapps/dolibarr/htdocs"

<Directory "/usr/share/webapps/dolibarr/htdocs">
    AllowOverride All
    Options FollowSymlinks Indexes
    Require all granted
</Directory>

# vim: set ft=apache ts=2 sw=2 et:
DELIM

echo "#dolibar" >> /etc/httpd/conf/httpd.conf
echo "Include conf/extra/httpd-dolibarr.conf" >> /etc/httpd/conf/httpd.conf

systemctl restart httpd.service

After that, I wanted to open my http://<hostname>/dolibarr and it worked out quite well. The build in installation routine started and I was able to click to the next page to check the system.
Almost all went well but it took me hours to figure out why the installation routine complained about the conf.php file. It had the right permissions (u+rw) but the php built in is_writable is returning false for this file.

It wasn't a running selinux, it wasn't a wrong configured php open_basedir or php safemode. It really turned out, that apache http refuesed to allow writing to a file outside than the configured home path of /srv/http.
Even a softlink created in /srv/http linking to /usr/share/webapps/dolibarr was not working.
What was working is to mv /usr/share/webapps/dolibarr /srv/http and to adapt the httpd-dolibarr.conf.

Zabbix: Required parameter $sql_parts follows optional parameter $table_alias

We are running our monitoring solution zabbix on an arch linux system. Arch linux tends to be "up to date" since it philosophie is "patch current code base, not legacy".

I've updated the monitoring system and with that, the php version jumped from 7.4.x to 8.0.x.

After that, a lot of "widgets" (boxes) in the zabbix frontend displayed me a lot of the following error.

Required parameter $sql_parts follows optional parameter $table_alias [zabbix.php:22 → require_once() → ZBase->run() → CSettingsHelper::getGlobal() → CSettingsHelper::loadParams() → API::getApiService() → CRegistryFactory->getObject() → CApiService->__construct() → CApiService->pk() → CApiService->getTableSchema() → CAutoloader->loadClass() → require() in include/classes/core/CAutoloader.php:77]

I've researched it and found that the error exists in the DB.php class. I've opened the issue Ticket ZBX-18984 and created the pull request 39 on the github source code. Hopefully, this fix will make it quickly into the code. I've added a git patch file to the issue. You can download and apply it on your system.

Using thecodingmachine docker images with podman

I wanted to quickly develop something. I thought this is the perfect timing to migrate mentally from the insecure and almost dead docker to the alive and secure podman.

I went to the page of thecodingmachine and tried it with the following one-liner:

podman run -p 80:80 --rm --name php-bazzline -v "$PWD":/var/www/html thecodingmachine/php:7.4-v3-apache

Sadly nothing is working so I've created a feature request asking for podman support.

My current workaround is following

sudo -c "echo '<username>:100000:65536' >> /etc/subuid"
sudo -c "echo '<username>:100000:65536' >> /etc/subgid"
sudo reboot

And adapt the start up as following to prevent port issues (you are not allowed - by default - to use ports below 1024).

podman run -p 8080:80 --rm --name php-bazzline -v "$PWD":/var/www/html thecodingmachine/php:7.4-v3-apache

Thats it.

Running Contao 3.x version and upgrading from PHP 5.x to PHP 7 results in a 500 Status?

I had the joy to debug a not working contao system line by line.

Why line by line? Because there was no entry in any logs, even with "log all motherfucker"-php.ini values on.

After parsing the lines, I ended up into this error message.

Fatal error: Cannot use 'String' as class name as it is reserved in ... system/modules/core/library/Contao/String.php on line 28

Well, nice to know the error but where was this triggered? So another round with joy and I ended up with an extension, of course installed "by hand" which means not possible to update by the contao updater and this lovely line.

$this->import('String');

After I've changed that line to the following line, all the gizmos where working again.

$this->import('StringUtils');

So, what should you do when you where faced with a 500 Apache Status Code after a contao installation moved from an PHP 5.x runtime environment to a PHP 7.x runtime environment?

cd <project root> grep -ir "import('String');" *

Replace >>import('String');<< with >>import('StringUtil');<< and that is it.

But all would be better if you are not installing extensions by hand.