A webhosting client reported that he wasn’t able to connect to the admin area of Zen Photo.  My web service uses Plesk. His previous webhosting was under Cpanel. I first uploaded the setup files of his version of Zen Photo. Then I asked him to perform the update. This failed by an internal server error (500). The first thing I did at that point was looking through the logfiles. The log contain the following errors

mod_fcgid: stderr: PHP Warning: file_exists(): open_basedir restriction in effect. File(/var/lib/php5) is not within the allowed path(s):

To resolve this I added the path /var/lib/php5 to the allowed list. This is a slight security risk. Most binaries are located in the allowed list anyways so I added the configuration like below:

After this configuration change the users was able to connect to the admin area and also capable of upgrading Zen photo to the last stable built.

However quite soon after that the user started to report another problem. When he was browsing through the admin area he experienced internal server errors again. I started to look at the log files for that user and the following error was reported:

[core:error] [pid 5159] [client x.x.x.x:49520] End of script output before headers: admin-options.php, referer: 
[fcgid:warn] [pid 5159] (104)Connection reset by peer: [client x.x.x.x:49520] mod_fcgid: error reading data from FastCGI server, referer

The log reported this error from many different reference scripts. Mostly any reference script. By then I tried many things from disabling the XSS protection. Disabling HSTS, Disabling PHP modules and changing the file and folder permissions. I started looking at the error log of apache2 server located in /var/log/apache2/error.log. The following error caught my eye:

[fcgid:error] [pid 1886] mod_fcgid: process /var/www/cgi-bin/cgi_wrapper/cgi_wrapper(7917) exit(communication error), get unexpected signal 11
[fcgid:error] [pid 1886] mod_fcgid: process /var/www/cgi-bin/cgi_wrapper/cgi_wrapper(8193) exit(communication error), get unexpected signal 11

The first thing I thought was that the account of that user did not have enough permissions over the wrapper script. But that was not the case. So at that point I was able to rule out the web server and any file permissions. I somehow got the idea that this error must have had something to do with the difference in it’s PHP version between mine server at the one of the previous hoster. So I had an older server with PHP 5.3 installed. I migrated the account of that customer to that older server and let him recheck. The user reported no issue at all. PHP 5.3 uses xcache and PHP 5.5 uses the newer opcache as Zend extension. So what I did was changing an PHP configuration file (/etc/php5/apache2/conf.d/05-opcache.ini) from this:

; configuration for php ZendOpcache module
; priority=05
zend_extension=opcache.so

into this

; configuration for php ZendOpcache module
; priority=05
#zend_extension=opcache.so

I restarted the web server and have the customer look again. He did not find any issues. Of course this causes many issues on the server. I quickly reverted the file to the previous version.

Ultimately resolving this issue I did the following to his PHP configuration:

 

opcache.enable=0

 

I am so happy with Plesk and all it does to make my life easier.