Concrete5 install issues: fastcgi leaves directories not writeable, and cgi wrapper is giving premature end of script

Help! (Home for newbies)
1

Hi there,

So far Virtualmin looks great, although I’m having some issues trying to get concrete5 up and going.

When using fastcgi (and running as the virtual servers owner) the php function is_writable seems to returning false on certain key directories causing concrete5 to prevent installation. The directories in question are owned by the virtual server owner and are 755. Has anyone seen this or know what the issue might be?

A fix suggested on the forums was to use CGI wrappers in conjunction with configuring cgi.fix_pathinfo=0. I’ve done this and updated both $HOME/etc/php.ini and $HOME/etc/php5/php.ini to set cgi.fix_pathinfo=0 with no luck. I’m still getting the following in my error_log:

Premature end of script headers: php5.cgi, referer: .... script not found or unable to stat: /home/arpsoft/cgi-bin/php5.cg, referer: ...

Any idea’s as to what either of the issues are and how the can be fixed?

Also would using the PRO version remove this issue with it’s more advanced PHP support (and is there a possibility of a concrete5 installer??)

Thanks in advance

Andrew

Version Info: Using Virtualmin GPL 3.83 on Ubuntu 10.04 LTS (Linode) and PHP Version 5.3.2-1ubuntu4.7

P.S.I’ve also have to update concrete5’s index.html as per http://www.concrete5.org/community/forums/installation/using_request_uri_instead_of_path_info_to_use_pr/ but removing it makes no difference (except the concrete5 installer complains).

2

Howdy,

Virtualmin Pro wouldn’t fix the issues you’re seeing – in theory, it should work just fine on Virtualmin GPL :slight_smile:

When running in the FCGID mode, it should run as the Virtual server owner, so you shouldn’t have any permissions issues.

There was an issue in the past with Ubuntu 10.04 that caused mod_php to take precedence, even when FCGID or CGI is setup.

The fix for that was to edit /etc/apache2/mods-enabled/php5.conf, and comment out the two SetHandler lines in it. After doing that, you’d need to restart Apache.

Does that by chance do the trick for you?

-Eric

3

Howdy, thanks for the quick reply.

I had a quick look but my php5.conf already has them commented out…

# SetHandler application/x-httpd-php # SetHandler application/x-httpd-php-source # To re-enable php in user directories comment the following lines # (from to .) Do NOT set it to On as it # prevents .htaccess files from disabling it. php_admin_value engine Off

Bugger…

My ubuntu installation is “brand new” so to speak, installed it, did the upgrade then installed virtualmin… so I’m sort of stumped. Do you have any other ideas?

On the Virtualmin PRO side, do you know if the rails support works for ruby 1.9.2/rails 3 on 10.04, specifically since 10.04 pegs gem to a pretty old version. In my initial playings I installed RVM to get around this but wasn’t sure if/how the PRO version handled these isses.

Thanks for your help

Cheers
Andrew

4

Howdy,

Well, the thing to do would be to verify that it’s really running as your userid, and not as mod_php.

You may want to create a file called “test.php”, and add this in it:

<?php phpinfo(); ?>

It should mention something about using CGI or FCGID/FastCGI as the Server API, and I believe you’d also see the userid in all that.

As far as what Virtualmin Pro supports – while I don’t know the specifics off the top of my head, I’d expect it to work with the Ruby/Gem versions that come with the distro.

Virtualmin doesn’t generally package it’s own software versions – it just works to control the software that’s installed on the distro you’re running.

-Eric

5

Couldn’t see a user id in the phpinfo() output so I put in a getmyuid() call and it’s using the correct uid. The server api reported by phpinfo() is CGI/FastCGI so it looks to be fine. This is same if I’m using fastcgi or CGI Wrapper.

It’s quite a pain that the CGI Wrappers give me one error and fast cgi another! I’d be happy to get either working… It might be worth me testing a different different distro and seeing if the issues persist.

Thanks for the Ruby info, may also point to using a different distro.

Thanks again for your help, if you have any other pointers for digging around would be greatly appreciated.

Cheers
Andrew

6

Hmm, getting the CGI mode to work is usually pretty straight forward. Something seems awry, but I’m not quite sure what :slight_smile:

You had mentioned this error in CGI mode:

script not found or unable to stat: /home/arpsoft/cgi-bin/php5.cg, referer: …

I missed this the first time around, but that looks like it’s looking for a “php5.cg” rather than “php5.cgi”. Is that what’s in the logs, or is that just a copy and paste problem?

Also, when using CGI mode, if you look in /home/arpsoft/cgi-bin/, what files do you see in there?

-Eric

7

Yep that’s correct, the logs are saying “php5.cg” (not a copy & past issue). /home/arpsoft/cgi-bin/ has a single file “php5.cgi” with the following content:

#!/bin/bash PHPRC=$DOCUMENT_ROOT/../etc/php5 export PHPRC umask 022 SCRIPT_FILENAME=$PATH_TRANSLATED export SCRIPT_FILENAME exec /usr/bin/php5-cgi

It would be nice to know what’s actually triggering the issue, since the basic php info script is running I might need to dig into concrete5 install script and put some debugging in there… bugger (c:

8

Ok, looking at what concrete5 is generating when using CGI wrappers it’s obvious the urls are getting buggered somewhere along the way. E.g. the source contains stuff like this.

<img src="/cgi-bin/php5.cg/concrete/images/icons/tooltip.png"

I presume concrete5 shouldn’t be putting the /cgi-bin/php5.cgiprefix in at all (I’m relatively new to the php world, spent many years in Java).

I’ll have a closer look in concrete and see if I can see what’s going on.

Cheers

9

Howdy,

Some web apps have problems with certain PHP versions, and possibly certain execution modes.

One thing you may want to try when using CGI mode is to edit $HOME/etc/php.ini, and set this:

cgi.fix_pathinfo=0

After that, give it another try and let us know if that helps!

-Eric

10

Yeah I’d read about that in another post and had already tried it (in both $HOME/etc/php.ini and $HOME/etc/php5/php.ini). Calls to phpinfo() are showing cgi.fix_pathinfo = 0 so it seems it’s configured ok.

When reading other posts this change has fixed things for other concrete5 users, but I’m not sure what version they’re using (I’m using the latest). I’ll still hunting through the source to find where the URLs are generated so I can see if it’s concrete or an underlying php config issue.

Cheers

11

Ok, found where concrete is buggering the url (and dropping the i). It’s making some assumptions about paths that aren’t true/valid in my set up.

if (!defined('DIR_REL')) { $uri = substr($_SERVER['SCRIPT_NAME'], 0, strpos($_SERVER['SCRIPT_NAME'], DISPATCHER_FILENAME) - 1); define('DIR_REL', $uri); }

Printing out the results I get:

[error] $_SERVER['SCRIPT_NAME']=/cgi-bin/php5.cgi [error] DISPATCHER_FILENAME=index.php [error] $uri=/cgi-bin/php5.cg

Hence the $uri= substr(…) call is making assumptions that aren’t true. Not sure what would happen in a normal environment.

By forcing DIR_REL=’’ I get the install page to render as per the fastcgi mode (i.e. it renders but it still thinks the directories aren’t writable by the webserver). Actually it’s a bit worse than fastcgi mode as the fix as per http://www.concrete5.org/community/forums/installation/using_request_uri_instead_of_path_info_to_use_pr no longer works.

Ok, so given the wrapper won’t fix things I see if I can figure out why concrete doesn’t think the directories are writable…

Cheers

12

Solved, mostly.

It turns out the “not writable by the web server” problem was a “user” error (mercurial removes empty directories so one of the required ones was missing due to a faulty filter in my .hgignore file). Adding it back in has fixed it and I can now proceed with the install step.

There still seems to be quite a lot broken with concrete5 when using CGI Wrappers but since it’s working with fastcgi (so far) I’m happy (c:

Thanks for all your help.

Cheers
Andrew