We've been using debian 8 perfect server setup with ispconfig 3.0.5.4p9 without issue for a number of servers all running php-fpm. Oddly, we just deployed another in exactly the same way and created a site running php-fpm only to find basic php code not executing such as phpinfo. The errors we were getting look like this: [fastcgi:error] [pid 1221] [client x.x.x.x:9576] FastCGI: incomplete headers (0 bytes) received from server "/var/www/clients/client1/web2/cgi-bin/php5-fcgi-y.y.y.y-80-host.domain.com" [Fri May 20 00:00:12.611455 2016] [fastcgi:error] [pid 1294] (13)Permission denied: [client x.x.x.x:9577] FastCGI: failed to connect to server "/var/www/clients/client1/web2/cgi-bin/php5-fcgi-y.y.y.y-80-host.domain.com": connect() failed We chmod'd 666 the .sock files in /var/lib/php5-fpm based on this discussion: http://serverfault.com/questions/57...ubuntu-12-10-500-error-or-returns-text-not-ex The question is, why is this necessary? We also found that on the affected server, if we create a new site we have to repeat the chmod change as above for the new site. Would appreciate input on this, thanks.
The problem with the chmod 666 is that you opened the PHP instance for all websites, so any website can run PHP scripts under the user of another website then. So this should be used just as temporary workaround as it does not provide a secure solution. Posible sources of the problem might be: 1) Is SELinux or a similar mechanism installed that might disallow connections to the socket even if user and group match? 2) Do you use advanced ACL' in that filesystem that might restrict access to the socket?
Good to know, thanks Till. Unfortunately we are still unsure how this has happened on this particular installation. SELinux is not enabled and we are not using advanced ACLs. Any other suggestions on troubleshooting? We have perused apache logs and php5-fpm.log without finding much in the way of clues.
Hi Till, Any other comments? We just had another server exhibit the same issue while we have several that do not, quite puzzling. Thanks
Do all new servers that you install have the issue, or just some of them? Are all installed in the exact same way?
hi till they are all installed in exactly the same way yes configured from the same virtual disk that we just copy and then configure with the particulars of that server, we have several, maybe 5-8 that never had this problem, the last two do -- the version of ispconfig is not different between the ones that do and do not so the only thing we can imagine is that there is some update present on these latter ones that have the issue, we have two now where the issue is reproducible
Is this a virtual server? If yes, which virtualisation is used? I remember that lxc has changed something in their code which can break sockets inside virtual machines, so if you use lxc, then this might be related.
hi till, yes, kvm virtualization is used, we have been doing this with ispconfig for a long time and have had no problems generally, thanks
Hmm, my best bet is still that it is something like apparmor, selinux or acl that prevents access to a socket which has correct permissions. Maybe these security settings get set from the hypervisor, at least in lxc this happens. So maybe a direct comparison of the kvm config file of a working and non working vm might shed some light on this. I just tested here on vmware workstation and php-fpm with sockets works as usual, all Debian updates installed and rebooted. Maybe you can test something on your server (I use web1 as example here, change that to number that matches your config): 1) Edit the php-fpm pool configuration file /etc/php5/fpm/pool.d/web1.conf and change the socket line from: listen = /var/lib/php5-fpm/web1.sock to listen = /var/run/web1.sock 2) Then edit the vhost file of the website: /etc/apache2/sites-available/test.tld.vhost. Inside that file you find a line for FastCgiExternalServer which also contains the socket path /var/lib/php5-fpm/web4.sock, change that to /var/run/web1.sock as well. Then restart apache2 and the php-fpm daemon (or reboot the vm if you want to be completely sure). Then test if php-fpm works now (without altering the socket permissions). If this is the case then we have a restriction from a security kernel addon that prevents sockets in /var/lib/php5-fpm/ directory but allows them in /var/run/
Hello Till, Thanks for the suggestions. I went ahead and did a clean install (very carefully) of the perfect server setup with debian 8 and I was able to reproduce the same behavior. I don't see how this can be related to the hypervisor as we have several servers that do not have this trouble and they are configuration duplicates of ones that do have the problem (within the hypervisor). I also did the test you mentioned using /var/run/webX.sock and the problem remains - and is immediately alleviated if /var/run/webX.sock has it's permissions changed to 666. Another issue is that if any changes are made to a given site within ispconfig then the permissions change to mode 666 must be manually applied again. While we are working on this, could you elaborate a little bit more on what the security weakness is with permissions of 666? That is, what would a user have to do in order to run php code under a different user? Also, we have servers we need to deploy very soon where this would be highly problematic and we would like to resolve this ASAP so any suggestions or workaround would be much appreciated. Regards, Ron
The permissions of the Linux file system are grouped into: user - group - other. so 6 -6 -6 assigns read and write permissions to user - group and other while 6 - 6 - 0 assigns them zo user and group only. So all the user ahs to do with 666 permissions is to write a small script or program that connects to the socket of another website and sends a command to it which then gets executed under the user of the other site. The problem with this issue is that it is not reproducible here by any of the developers. We install new servers every few days by using the perfect setup guide as basis and they all are working. Maybe you can make one of your servers available to use (we need root login and ispconfig admin login to a test machine) so we can check the issue on your server. You can contact me by email to dev at ispconfig dot org.
We checked the issue on another system today which also uses kvm and has the same symptom that old vm's work and new dont work. The config of the vm is fine and the permissions are correct but it still does not work. The best workaround, for now, is to edit the file: cp -pf /usr/local/ispconfig/server/conf/php_fpm_pool.conf.master /usr/local/ispconfig/server/conf-custom/php_fpm_pool.conf.master vi /usr/local/ispconfig/server/conf-custom/php_fpm_pool.conf.master and change the line: listen.group = <tmpl_var name='fpm_group'> to: listen.group = www-data new and updated websites should be working then.
