Error When Switching Virtual Host PHP script execution mode to "FCGId (run as virtual server owner)"

18 posts / 0 new
Last post
#1 Fri, 04/20/2012 - 14:58
promedia

Error When Switching Virtual Host PHP script execution mode to "FCGId (run as virtual server owner)"

I really want to setup a server of virtual hosts where each website runs as it's virtual host owner rather than as apache, mostly because this is an optimal setup for WordPress and other CMS. So after research I chose Virtualmin to help me achieve this using the FCGId method.

After setting up a virtual host, I switch the PHP Script execution mode from "Apache mod_php (run as Apache's user)" to "FCGId (run as virtual server owner)" and my site returns "500" Internal Server Error".

Output of error logs follows:

----------------- Virtual hosts logs/error_log:  --------------------
[Fri Apr 20 05:27:51 2012] [warn] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error.
[Fri Apr 20 05:27:51 2012] [error] [client 64.115.91.114] Premature end of script headers: phpinfo.php
------------------------------------------------------------------------------------

----------------- etc/httpd/logs/error_log:  --------------------
[Fri Apr 20 05:27:51 2012] [notice] mod_fcgid: call /home/****/public_html/phpinfo.php with wrapper /home/****/fcgi-bin/php5.fcgi
suexec policy violation: see suexec log for more details
------------------------------------------------------------------------------------

----------------- etc/httpd/logs/suexec.log:  --------------------
[2012-04-20 05:27:49]: uid: (505/****) gid: (505/505) cmd: php5.fcgi
[2012-04-20 05:27:49]: command not in docroot (/home/****/fcgi-bin/php5.fcgi)
------------------------------------------------------------------------------------

Other Important Information

Output of /usr/sbin/httpd -V

Server version: Apache/2.2.3
Server built:   Oct 20 2011 17:00:12
Server's Module Magic Number: 20051115:3
Server loaded:  APR 1.2.7, APR-Util 1.2.7
Compiled using: APR 1.2.7, APR-Util 1.2.7
Architecture:   64-bit
Server MPM:     Prefork
  threaded:     no
    forked:     yes (variable process count)
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT="/etc/httpd"
-D SUEXEC_BIN="/usr/sbin/suexec"
-D DEFAULT_PIDLOG="run/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"

Output of php -v

PHP 5.3.10 (cli) (built: Feb  2 2012 17:34:38)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
    with eAccelerator v0.9.6.1, Copyright (c) 2004-2010 eAccelerator, by eAccelerator
    with the ionCube PHP Loader v4.0.14, Copyright (c) 2002-2011, by ionCube Ltd., and
    with Xdebug v2.1.4, Copyright (c) 2002-2012, by Derick Rethans

Now this confused me - I found 2 instances of suexec.

/usr/sbin/suexec -V
-D AP_DOC_ROOT="/var/www"
-D AP_GID_MIN=100
-D AP_HTTPD_USER="apache"
-D AP_LOG_EXEC="/var/log/httpd/suexec.log"
-D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D AP_UID_MIN=500
-D AP_USERDIR_SUFFIX="public_html"

/usr/bin/suexec -V
-D AP_DOC_ROOT="/home"
-D AP_GID_MIN=100
-D AP_HTTPD_USER="apache"
-D AP_LOG_EXEC="/usr/local/apache2/logs/suexec_log"
-D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D AP_UID_MIN=100

From abundant (2 days worth) of research on this, I know that AP_DOC_ROOT needs to be "/home", from the suexec in /bin/. When I run /which suexex it replies "/usr/bin/suexec" So that appears to be correct.

I would really wish to avoid removing apache and reinstalling this server for like the fifth time... please help? Is there a way I can patch this?

Fri, 04/20/2012 - 15:19
andreychek

Howdy,

The setup you're describing should be the default -- without making any changes, it should use FCGID with suexec.

What distro/version are you using?

And how did you perform the Virtualmin installation, did you use the automated install.sh script, or did you perform a manual installation?

It appears as if you may be using a non-standard setup or unsupported distro... so figuring out the details about your distro and install method should help determine the source of the problem. It's related to suexec, as it's compiled with the wrong options -- I'm just not sure why yet :-)

-Eric

Mon, 04/23/2012 - 07:40
promedia

I installed Virtualmin through my webmin interface. "Version 3.91.gpl" I guess this leaves me with 3 questions.

Is suexec setup when Virtualmin gets installed?

Should I re-run it from the install script instead of from webmin? I do have shell access.

Do I have to uninstall anything first?

Mon, 04/23/2012 - 08:10
andreychek

Howdy,

Is suexec setup when Virtualmin gets installed?

Not when installing Virtualmin as a module from within the Webmin interface.

When doing that -- that's considered a manual installation, and you may want to review these instructions for doing that:

https://www.virtualmin.com/documentation/installation/manual

Should I re-run it from the install script instead of from webmin? I do have shell access

Well, the install.sh script works best on a fresh install of your OS. Is this a fairly new server with little setup on it? Or is it fairly customized by now?

If you can, you might save yourself some trouble by formatting and starting with a fresh version of your OS. If you haven't done anything on your server yet other than install Webmin and Virtualmin, you could always give the install.sh a try.

If, on the other hand, you've already done a lot of customizing, you may want to take a look at the manual installation guide above/

Also, note that you'd want to make sure you're using a supported OS version. You can see those here:

https://www.virtualmin.com/os-support

-Eric

Mon, 04/23/2012 - 08:16
promedia

Yes i'm using a supported OS.. and I have setup some sites already on this server and done some customization, however I've gone and uninstalled apache, php and mysql in order to start fresh.. hopefully I don't lose the sites I already migragted to this new server because well, I don't think I backed them up all that well.

Mon, 04/23/2012 - 08:33
promedia

I think I just screwed up really badly. I removed my installations of apache, mysql, php and virtualmin. Now I'm trying to run the install script. And it is failing.

I put my install log here: http://pastie.org/3838995

I do see one potential error, something about shutting of SELINUX. Other than that I'm completely baffled... and I think I just wiped about half a dozen websites I've already migrated.. FML.

Mon, 04/23/2012 - 08:48
promedia

Well I turned off SELINUX manuall and got some better results.. now i'm left with this error:

Transaction Check Error:
  file /usr/lib64/mysql/libmysqlclient.so.15.0.0 from install of mysql-5.0.77-4.el5_6.6.x86_64 conflicts with file from package mysqlclient15-5.0.92-1.ius.el5.x86_64
  file /usr/lib64/mysql/libmysqlclient_r.so.15.0.0 from install of mysql-5.0.77-4.el5_6.6.x86_64 conflicts with file from package mysqlclient15-5.0.92-1.ius.el5.x86_64

When I initially started installing this server I was hoping to use the latest apache, php and mysql versions, I've installed some yum repo's like IUS and Remi... It looks like Virtualmin is using some much older software versions, but I've uninstalled everything now so why am I getting stuck here.

Mon, 04/23/2012 - 09:11
promedia

Making progress one small step at a time - found a hidden mysql bit and managed to remove it.. found that using yum list 'mysql*' with quotes returns better results than without the quotes.

Install.sh ran and seems like installed.. apache is installed among other things, but my VirtualMin Module in Webmin is missing. Is there something I have to do to set this up?

Also got a few more errors:

Resolving Dependencies
--> Running transaction check
---> Package php53-xml.x86_64 0:5.3.3-1.el5_7.3 set to be updated
--> Processing Dependency: php53-common = 5.3.3-1.el5_7.3 for package: php53-xml
--> Running transaction check
---> Package php53-common.x86_64 0:5.3.3-1.el5_7.3 set to be updated
--> Processing Conflict: php53-common conflicts php-common
--> Finished Dependency Resolution
php53-common-5.3.3-1.el5_7.3.x86_64 from updates has depsolving problems
  --> php53-common conflicts with php-common
You could try using --skip-broken to work around the problem
You could try running: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest
INFO - 2012-04-22 23:55:29 - There may have been a problem updating some packages.

Getting a bit sketchy now, my boss i breathing down my neck.. after I persuaded him 2 weeks ago a switch to linux from windows would save money.. now I've spent ove ra week on this migration and i may be looking for a new job soon.

Mon, 04/23/2012 - 09:25
andreychek

Howdy,

Yeah, you wouldn't want to run the installer on a server with live sites unfortunately... that's designed to work on a freshly installed version of your OS. The initial screen of the installer mentions this here:

If you have existing websites, email users, or if you manually installed Virtualmin via a Webmin 'wbm' module, you are likely to run into problems.

We generally hope folks don't go past that screen when any of that is the case :-)

If you already setup sites, they likely won't work after running the install.sh, as the installer changes how the Apache config functions.

Also, the error you're getting looks like you have have packages from a third party repository installed (some MySQL libs in your case) -- and they appear to be conflicting with those that come with CentOS.

If there's anything you could do to perform a fresh install of your OS, run the installer, and then migrate your sites back, that'd be the best option.

But since you have live sites already, I would not recommend the install.sh script, you would need to do a manual installation if you can't format and start over.

You should be able to correct the Apache issue(s) you're having. What is happening at the moment, is it that the sites are all going to the default website? If so, you can correct that by editing /etc/httpd/conf/httpd.conf, and look at the various "VirtualHost" blocks towards the bottom of the file.

I suspect they'd be listed there as "VirtualHost *:80" -- you may need to change those to instead read "VirtualHost x.y.z.q:80", where x.y.z.q is your server's IP address.

-Eric

Mon, 04/23/2012 - 10:13
promedia

well I'm asking my server host to reprovision the server for me, to set it back to square one so I can do this right. Can you give me an idea of what I should do VERY VERY FIRST and what to configure ahead of time, on a freshly installed OS to get virtualmin and webmin installed and running properly with SUEXEC - I know there is documentation but, is there anything else I should try to be aware of so I don't get my ass fired.... which it may already be...

Mon, 04/23/2012 - 10:24
andreychek

Howdy,

I'm not sure that I would suggest attempting to continue the install.sh process, due the the reasons described in my comment above about this not being a fresh OS installation... but if you were interested in that anyhow, we can certainly discuss the issues you're seeing.

You mentioned this error:

--> Processing Conflict: php53-common conflicts php-common
--> Finished Dependency Resolution

The problem there is related to this not being a fresh install -- the Virtualmin installer doesn't expect to see php 5.3 installed, as php 5.1.6 is installed by default on CentOS 5.

If you want to try to continue with the installer, you could temporarily replace the php53-* packages you have installed with their older php-* versions -- that would allow the installer to complete. And then, once that finishes, you could reinstall the php53-* packages you have installed now.

But since you already have your sites setup, you aren't going to be dealing with a simple situation here -- you still have a bit of configuration and tweaking ahead of you :-)

-Eric

Mon, 04/23/2012 - 10:55
promedia

I had my host format and re-install the server.

I ran install.sh (FRESH OS INSTALL)

Still getting this:

php53-common-5.3.3-1.el5_7.3.x86_64 from updates has depsolving problems
  --> php53-common conflicts with php-common
You could try using --skip-broken to work around the problem
You could try running: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest
The program package-cleanup is found in the yum-utils package.
FATAL - 2012-04-23 01:23:00 - Fatal Error Occurred: Something went wrong during installation: 0
FATAL - 2012-04-23 01:23:00 - Cannot continue installation.
FATAL - 2012-04-23 01:23:00 - Attempting to remove virtualmin repository configuration, so the installation can be
FATAL - 2012-04-23 01:23:00 - re-attempted after any problems have been resolved.
FATAL - 2012-04-23 01:23:00 - Removing temporary directory and files.

That is a brand new reformat and reprovision of the server. I think the problem is that YUM wants to install the php53 updates available on 5.3.3-1.el5_7.3 --- I think this is a case of the install script and virtualmin not being up to date on packages..... I suppose I can try removing the repo...

--- or can I install php53 first ???? and still run the virtualmin install script after?

Mon, 04/23/2012 - 11:07
andreychek

Howdy,

On a fresh install of CentOS 5, it shouldn't be dealing with php53 packages.

The php53 packages aren't installed by default (unless perhaps your provider has a special CentOS image that is including php53).

My recommendation would be to remove any package with "php53" in it's name, and to try running the installer again.

You can see what those are by running this command:

rpm -qa | grep php53-

-Eric

Mon, 04/23/2012 - 11:23 (Reply to #13)
promedia

= rpm -qa | grep php53- returns nothing at all.

= there is no php53 installed at all. I did this

[root]# yum list installed | grep php
php.x86_64                                  5.1.6-27.el5_5.3           installed
php-cli.x86_64                              5.1.6-27.el5_5.3           installed
php-common.x86_64                           5.1.6-27.el5_5.3           installed
php-devel.x86_64                            5.1.6-27.el5_5.3           installed
php-gd.x86_64                               5.1.6-27.el5_5.3           installed
php-imap.x86_64                             5.1.6-27.el5_5.3           installed
php-mbstring.x86_64                         5.1.6-27.el5_5.3           installed
php-mysql.x86_64                            5.1.6-27.el5_5.3           installed
php-odbc.x86_64                             5.1.6-27.el5_5.3           installed
php-pdo.x86_64                              5.1.6-27.el5_5.3           installed
php-pear.noarch                             1:1.4.9-6.el5              installed
php-pgsql.x86_64                            5.1.6-27.el5_5.3           installed
php-snmp.x86_64                             5.1.6-27.el5_5.3           installed
php-xml.x86_64                              5.1.6-27.el5_5.3           installed
php-xmlrpc.x86_64                           5.1.6-27.el5_5.3           installed
wbm-php-pear.noarch                         2:1.5-1                    installed

Which must have been installed during my last attempt to run the install script, because previously no PHP was installed at all.

Still getting this: When the install script is checking for updates to Virtualmin-related packages...

INFO - Checking for updates to Virtualmin-related packages...
...in progress, please wait...                                                                                           |Error: php53-common conflicts with php-common                                                                            /usr/bin/yum -y -d 2 install bind bind-utils caching-nameserver httpd postfix spamassassin procmail perl-DBD-Pg perl-DBD-MySQL quota iptables openssl python mailman subversion mysql mysql-server mysql-devel postgresql postgresql-server rh-postgresql rh-postgresql-server logrotate webalizer php php-domxml php-gd php-imap php-mysql php-odbc php-pear php-pgsql php-snmp php-xmlrpc php-mbstring mod_perl mod_python cyrus-sasl dovecot spamassassin mod_dav_svn cyrus-sasl-gssapi mod_ssl ruby ruby-devel rubygems perl-XML-Simple perl-Crypt-SSLeay failed.  Error (if any): 0

Displaying the last 15 lines of /root/virtualmin-install.log to help troubleshoot this problem:
Package perl-Crypt-SSLeay-0.51-11.el5.x86_64 already installed and latest version
Resolving Dependencies
--> Running transaction check
---> Package php53-xml.x86_64 0:5.3.3-1.el5_7.3 set to be updated
--> Processing Dependency: php53-common = 5.3.3-1.el5_7.3 for package: php53-xml
--> Running transaction check
---> Package php53-common.x86_64 0:5.3.3-1.el5_7.3 set to be updated
--> Processing Conflict: php53-common conflicts php-common
--> Finished Dependency Resolution
php53-common-5.3.3-1.el5_7.3.x86_64 from updates has depsolving problems
  --> php53-common conflicts with php-common
You could try using --skip-broken to work around the problem
You could try running: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest
INFO - There may have been a problem updating some packages.

I've looked at /etc/yum.repos.d/ and cannot locate where to specifically eliminate the el5_7.3 branch of the repo.... I know this isn't exactly a virtualmin issue anymore - but it may be if these is starting to come with fresh server packages...

any final ideas before I just give up on virtualmin altogether?

Mon, 04/23/2012 - 11:50
promedia

----- derp.

I turned OFF my CentOS-Base Repo completely.. and score. Virtualmin installed.... problem solved.

Mon, 04/23/2012 - 12:47
andreychek

I'm glad you got it installed!

We saw the issue you're describing one other time, and we never did figure out what was causing it :-/

Now that things are installed though, you should have an easier time getting your sites up and running -- if you run into any additional issues, feel free to post them here and we can get them figured out!

-Eric

Mon, 04/23/2012 - 14:14
promedia

Actually there is one other thing now.. how do I go about safely updating my PHP version from 5.1.6 to something a little more up to date? I can't install phpmyadmin 3.5.0 on a virtual server because i t needs 5.2 or later. I don't want to update php if I'm going to go through all this again.

-- edit --

found the virtualmin bleeding repo - did the trick there.. --- it's all here if you look hard enough.. thanks for the assistance!

Mon, 04/23/2012 - 14:29
andreychek

Howdy,

Yup, using that bleeding edge repo is perfect, that's a nice and easy way to get 5.2.17.

It's also possible to use PHP 5.3.x, but there's a few more steps involved.

So if 5.2.x works for you, great!

-Eric