Failed opening required - Commentics & cgi-bin

[behindth]

(Note: This post is a reworking of a post at the Commentics forum.)

Hi all. I am reasonably proficient in PHP and HTML, but I recently became unhappy with one server I was using. I created an account here, and all seemed to be well until I tried to use the Commentics script. I didn't use it on my old server, but thought it would be good to implement for the new one. The script worked fine during local testing using a PHP module installed in Apache. When I uploaded what I had done to the new server, I got:

Fatal error: require_once() [function.require]: Failed opening required 'includes/variables/set_variables.php' (include_path='.:/usr/local/php53/pear') in /home/behindth/public_html/comments/includes/commentics.php on line 31

I have searched this forum for similar errors, but the vBulletin search returned:

The following words are either very common, too long, or too short and were not included in your search:
"failed opening required"

You guys familiar with CGI servers can probably solve this one quickly. My sever has a "cgi-bin" folder, and I've read online posts about having to run PHP scripts from that folder. I really don't understand running PHP as a CGI module. Will I have to run it from that folder? I don't really understand, if so, since my site's pages have a PHP extenstion, and they run just fine.

Anyway, to further try to chase down the problem, I made a script to test to see if the file is there:

<?php
    if (file_exists("comments/includes/commentics.php")) {
        print "File exists!\n";
    } else {
        print "File does not exist!\n";
    }
require "comments/includes/commentics.php";
?>

It prints:

File Exists.
Access denied.

I am also somewhat mystified that my script does not generate the full error, but the integration code does.

My integration code is:

<?php
$page_id = "1";
$reference = "test";
$path_to_comments_folder = "comments/";
define ('IN_COMMENTICS', 'true'); //no need to edit this line
require $path_to_comments_folder . "includes/commentics.php"; //no need to edit this line
?>

My commentics script installed just fine.

I saw a post, claiming you were running PHP in safe mode for free accounts; but someone replying denies this. The post that poster was referring to was talking about a popen function that was disabled, and would not be enabled for free accounts. Perhaps they have disabled "require"?

I suppose there is a Softaculous script to do something similar; and I'm open to considering one. I don't know what it would be, and I am now curious to find out the nature of this problem

 

[misson]

Note that Scripts, 3rd Party Apps, and Programming is a more appropriate forum for this issue (if you ask the admins, maybe one will move the thread).

To resolve this, first consider how the include and require special forms resolve relative paths:

1. check in each directory specified in include_path
2. check in the script's directory
3. check in the current working directory (unless chdir is called, this is the directory of the initial script or (for PHP-CGI) the PHP binary's directory)

Examining the various paths in the messages tell us what is happening:

• required script: includes/variables/set_variables.php
• requiring script: $DOCROOT/comments/includes/commentics.php
• include_path: .:/usr/local/php53/pear
• file_exists test: comments/includes/commentics.php
• included commentics script: comments/includes/commentics.php
• including script: $DOCROOT/???.php

Note that including anything in comments/includes/ works from a script in $DOCROOT, but including anything in includes/ fails, no matter the location. The former path works because the initial script is in $DOCROOT and comments is a sub-directory of $DOCROOT (hence, any method in the first list will resolve "comments/includes/..."). The latter path fails because $DOCROOT/comments isn't in the include path, any of the script's directories or the current working directory, hence no method can resolve "includes/...". This goes to show how useful it is to read the manual when something isn't working the way you expect (because typically that means your expectations are wrong).

Fixes become obvious. The path used when requiring the script isn't resolvable by method 1, 2 or 3, so something must be changed so one of the methods will work. There are three things that can be changed: include_path, the location of the scripts and the paths used in the failing require_once statements. Any of the following should work:

1. add the necessary directory ($DOCROOT/comments) to the include path.
2. move the contents of the comments directory to somewhere on the include path or ($DOCROOT) and remove "comments/" from any relevant include or require line.
3. correct the path in the failing require_once lines (prefix "comments/" or remove "includes/"). As this requires changing 3rd party source, it wil complicate upgrades and is the least desirable solution.

If the commentics scripts contains no entry points, I would recommend a combination of 1 and 2: move the commentics scripts outside the web hierarchy (e.g. $HOME/lib/php) and add that folder to the include path. Not only will this correct the include issue but make the scripts not directly accessible as web pages (otherwise someone could access e.g. "comments/danger.php" as http://example.com/comments/danger.php).

I have searched this forum for similar errors, but the vBulletin search returned:

The following words are either very common, too long, or too short and were not included in your search:
"failed opening required"

As the notice says, the phrase is too long. Leave off the quotes and search for failed opening required.

You guys familiar with CGI servers can probably solve this one quickly. My sever has a "cgi-bin" folder, and I've read online posts about having to run PHP scripts from that folder. I really don't understand running PHP as a CGI module. Will I have to run it from that folder? I don't really understand, if so, since my site's pages have a PHP extenstion, and they run just fine.

The posts may have been talking about putting the PHP binary in cgi-bin, but shouldn't have said that about PHP scripts. You don't need to (and shouldn't) put PHP scripts in your cgi-bin folder. CGI is an interface that allows the web server to pass HTTP requests off to external applications for handling. It defines how the external programs are run, what information is passed to them and how the information is passed. Just because PHP and executables in cgi-bin are set up to use CGI doesn't mean everything needs to be placed in cgi-bin. By analogy, consider a computerized elevator system. Security control panels (PHP) and button panels (CGI scripts) in elevators (cgi-bin) must interface with the same system (use the same interface), but security panels don't need to be in an elevator (PHP scripts don't need to be in cgi-bin). Beyond all of that, no CGI scripts will currently run from the cgi-bin folder on the free X10 hosts, as it was disabled due to abuse.

Under Apache (which is what is covered by most of the information you've read and that you'll find online), the ScriptAlias directive is used to configure cgi-bin directories as containing CGI scripts. A PHP CGI set-up uses the same directive to make the php binary accessible as a CGI program (the directory containing the binary is set up as a script alias), but it's a separate config line, plus some additional directives (AddHandler and Action) are required so that PHP will actually handle PHP scripts. Note that for cgi-bin, the CGI programs are the scripts in the cgi-bin folder. The PHP binary is similarly set up as a CGI program. PHP scripts, however, are not CGI programs under a typical PHP CGI set-up.

However, the free X10 servers run LiteSpeed, not Apache (examine HTTP response headers to see this for yourself), and PHP runs as a LiteSpeed SAPI (LSAPI) program (calling php_sapi_name() in a PHP script shows this) rather than a CGI program. Moreover, under LiteSpeed, CGI programs in the cgi-bin folder are configured as a context, whereas the PHP interpreter is configured as an external application, a completely separate feature.

I saw a post, claiming you were running PHP in safe mode for free accounts; but someone replying denies this. The post that poster was referring to was talking about a popen function that was disabled, and would not be enabled for free accounts. Perhaps they have disabled "require"?

require isn't disabled by default in safe mode; doing so would make no sense, as it would cripple scripts far too much (all scripts would need to be self-contained, killing code reuse). The PHP manual lists many of the functions restricted or disabled by safe mode, and none of the include special forms are listed. Safe mode does perform additional checks (in particular, that an accessed file has the same owner as the script), which can affect the include forms, but it would result in a different message and (as you uploaded all the files) they should all have the same owner.

Safe mode was enabled at one point, but no longer as safe mode was deprecated in PHP 5.3. A very recent thread (5 days ago, as of this post) has a confirmation of this by Corey, one of the server admins. Always check the date of any posts you read; if it concerns server config and it's more than a year old, it's out of date. Even if it's only a few months old, the server config could have changed since then, so search for a newer thread that mentions the same configuration setting.