I’ve just reinstalled my server’s OS (Ubuntu 10.04 LTS) and installed Virtualmin using install.sh. Everything is completely vanilla - the only thing I’ve done after logged into the clean system is to run install.sh and enable the userdir Apache module.
I’ve created a virtual host and logged into its account using SFTP, then created a php file with phpinfo() in it. When I browse to the file I get a 500 Internal Server Error.
Apache’s error.log shows this:
[Fri Jan 27 10:20:46 2012] [notice] mod_fcgid: call /home/username/public_html/info.php with wrapper /home/username/fcgi-bin/php5.fcgi
suexec policy violation: see suexec log for more details
[Fri Jan 27 10:20:52 2012] [notice] mod_fcgid: process /home/username/public_html/info.php(28890) exit(communication error), terminated by calling exit(), return code: 112
and suexec.log has this:
[2012-01-27 10:20:46]: uid: (1000/username) gid: (1000/username) cmd: php5.fcgi
[2012-01-27 10:20:46]: cannot get docroot information (/home/username)
and the virtual host’s error_log has this:
[Fri Jan 27 11:07:02 2012] [warn] [client 18.104.22.168] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server
[Fri Jan 27 11:07:02 2012] [error] [client 22.214.171.124] Premature end of script headers: info.php
I’ve tried altering cgi.fix_pathinfo in /home/domain/etc/php.ini to On/Off/1/0 but none of them made any difference.
Obviously the problem is with suexec, but I’ve been playing about with this server for a few days trying to get the config right (and having little success) and this time I’m going to seek help before I touch anything and potentially make it worse
Any help would be really appreciated
Hmm, suexec seems to be mighty confused there.
Can you check the permissions on your user’s home directory there?
For example, try running this command:
ls -la /home/USERNAME
When you do that – are the owner of all the files and directories (with the exception of “…”) owned by your user?
Hi there, thanks for responding.
Yes they’re all username:username:
root@server:/etc/apache2/suexec# ls -la /home/plastikwrap
drwxr-x--- 10 plastikwrap plastikwrap 4096 2012-01-27 16:59 .
drwxr-xr-x 6 root root 4096 2012-01-27 17:11 ..
-rw------- 1 plastikwrap plastikwrap 29 2012-01-27 16:59 .bash_history
-rw-r--r-- 1 plastikwrap plastikwrap 220 2012-01-27 10:17 .bash_logout
-rw-r--r-- 1 plastikwrap plastikwrap 3103 2012-01-27 10:17 .bashrc
drwx------ 2 plastikwrap plastikwrap 4096 2012-01-27 10:19 .cache
drwxr-x--- 2 plastikwrap plastikwrap 4096 2012-01-27 10:17 cgi-bin
drwxr-xr-x 3 plastikwrap plastikwrap 4096 2012-01-27 10:17 etc
drwxr-xr-x 2 plastikwrap plastikwrap 4096 2012-01-27 10:17 fcgi-bin
drwxr-xr-x 2 plastikwrap plastikwrap 4096 2012-01-27 10:17 homes
drwxr-x--- 2 plastikwrap plastikwrap 4096 2012-01-27 10:17 logs
-rw-r--r-- 1 plastikwrap plastikwrap 675 2012-01-27 10:17 .profile
drwxr-x--- 2 plastikwrap plastikwrap 4096 2012-01-27 10:19 public_html
drwxr-x--- 2 plastikwrap plastikwrap 4096 2012-01-27 10:17 tmp
I’ve not changed any permissions manually on those files or directories.
Okay, what if you go into System Settings -> Re-Check Config, does it notice anything unusual?
We had similar errors:
(104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server
Premature end of script headers: index.php
On a Debian 6.0 setup when a user uploaded via ftp files and somehow changed the permission on the fcgi-bin directory. It must be 755, and they had changed it to 775. Once we fixed that (and restarted apache) then all was well.
No, it says “your system is ready for use by Virtualmin.”
Thanks for the reply.
I tried chmod’ding the fcgi-bin/ directory to 755 and restarted apache and that didn’t change anything
I can’t change the permissions of fcgi-bin/php5.fcgi, even as root; it tells me the operation isn’t permitted (I’m surprised there’s anything that isn’t permitted as root!)
Just for fun, you might also try changing the PHP Execution Mode to see if that somehow resolves it.
If you go into Server Configuration -> Website Options, try changing the PHP Execution Mode to “CGI”.
If that doesn’t work, we might need to take a look at your Apache conf for this particular domain.
in the fcgi-bin directory:
lsattr php5.fcgi (to see what it is set to)
chattr -i php5.fcgi (then you can edit and/or change permissions)
chattr +i php5.fcgi (to set it back)
php5.fcgi should be 755 too.
Oh, and I had that docroot error before too, and to fix it I had to comment-out the SuexecUserGroup line in a virtual host conf file (say for host myvirtualhost):
Put a # before the SuexecUserGroup line.
Then of course Apply apache changes.
Thanks for your reply. I tried all of that but it didn’t make a difference
This is the result of lsattr php5.cgi:
/var/log/apache2/suexec.log still shows this:
[2012-01-28 10:09:12]: uid: (1000/plastikwrap) gid: (1000/plastikwrap) cmd: php5.fcgi
[2012-01-28 10:09:12]: cannot get docroot information (/home/plastikwrap)
and /home/plastikwrap/logs/error_log shows this:
[Sat Jan 28 10:09:12 2012] [warn] [client 126.96.36.199] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server
[Sat Jan 28 10:09:12 2012] [error] [client 188.8.131.52] Premature end of script headers: info.php
I don’t want to give in and use CGI just yet, because I feel that this should work, plus by all accounts FastCGI is better (though I’m no expert).
I know I use it for Debian. That also modifies allowable docroots, using this file:
The first two lines contain the suexec document root and the suexec userdir
suffix. Both features can be disabled separately by prepending a # character.
This config file is only used by the apache2-suexec-custom package.
Okay well I changed the execution mode to CGI and it’s executing PHP now, but link/image paths are all changed to “/cgi-bin/php5.cgi” which obviously breaks them
EDIT: i got rid of cgi.fix_pathinfo and it’s working now. Now to get APC working!
I’m still a bit disappointed that I can’t get fcgi to work, but I suppose cgi is better than nothing!
I had the same problem after a hot reboot of the system …
Solved the problem with a # before the SuexecUserGroup line.
I can’t explain what happened but now works after apache restart.