I have one staging server that stopped running cron jobs. After some research, it turns out that require_once was failing.
I've seen other related questions, and this has nothing to do with paths, absolute or relative. I can create a new file test.php, try to require it in the same folder with the file owner, and fail:
php -r 'include("test.php"); echo "hello\n"'
hello
php -r 'require("test.php"); echo "hello\n"'
PHP Fatal error...failed opening 'test.php'...include path .:/usr/share/pear:/usr/share/php'
Out of desparation, I moved test.php to /usr/share/pear/test.php, same error. Also I've tried ./test.php, __dir__."/test.php", same error.
PHP 5.3.3, which is dated, but working on 2 other servers (dev and prod)
Is it just broken?
Thank you for everyone's help. I wanted to post the solution.
Someone altered the php.ini file and set the open_basedir (to a fairly useless directory I might add), which essentially limited php functionality to that directory. Unfortunately this doesn't throw any useful error.
Thanks again!
Related
All of a sudden, my SMF powered forum has stopped working.
In fact, PHP files no longer seem to want to open on my website. I tried uploading a blank PHP file with just a few characters of text, and it refuses to open giving the error below.
I also tried a PHPinfo file, which didnt work, giving the same error. Other sites on the same server are working.
Fatal error: Unknown: Failed opening required '/home/users/a/n/mysite/www/index1.php' (include_path='.') in Unknown on line 0
Any ideas about whats gone wrong?
Just an idea. As it happens to all php files that could to what i know only mean 2 things.
Either there is somekind of error on the php extension.
OR what it most likely is, is that SMF uses a .htaccess to make user friendly links. Which means all requests to the server no matter what (Unless specified in the .htaccess) will be sent to index.php and then be handled.
So if there is a error in the index.php or the library of some sort it would explain why no matter what php file you're looking at it gives the error.
-
One thing you could do is to take a backup of all your images in the system. Then try to install a fresh version on your local machine. Once done copy/past the images back and copy all the current php files for SMF and replace the current ones on your host with them.
-
Haven't used SMF much so I'm not sure this is the solution at all. But to me it sounds like a solution.
It seems you have broken your root document.
do chmod 755 index1.php
and it should solve the problem.
You should check the php.ini or php5.ini file. I don't believe the single ticks around '.' for the include_path are valid. Double quotes will work however.
It seems you have been hacked:
http://wordpress.org/support/topic/fatal-error-unknown-failed-opening-required-google_verifyphp
Ahh sorry reread the question. I guess this is what you may try.
Check your file permissions. by default if your web server can not read files thats what you are going to get. I could be wrong but worth having a look
so just chmod your root folder to say 755 atleast
Note - this problem is resolved, but I'm posting here to find insight into what was happening because I don't understand.
My shared host's default configuration is PHP 5.2.17. When I asked them if I could upgrade to 5.3.X they said sure, and to quote:
A handler for PHP 5.3 is added to our shared and reseller servers for
those who wish to utilize it. In order to utilize this handler, you
will need to add the following code to your .htaccess file:
Action application/x-hg-php53 /cgi-sys/php53
AddType application/x-hg-php53 .php
To elaborate further on why we do not currently have this by default,
it is due to compatibility issues of older PHP scripts with the new
5.3 version. So, to prevent breaking the older scripts on our client's sites we have left the default PHP version as 5.2.X.
So I did that and quickly discovered that this killed my sites using PDO. Calling new PDO(); resulted in class not found errors in the log.
The shared host's support response was:
Our PHP 5.3 installations do have PDO enabled already. The issue here
appears to be caused by a custom php.ini based on the php.ini for PHP
5.2, so it attempts to load the PHP 5.2 modules instead of the PHP 5.3 modules.
ok seems reasonable, says I, now go ahead and fix that!
They updated the .ini file, and added the handlers to my .htaccess, and...
Your site appears to load correctly, but let us know if you find any problems.
which was true, now the main site and PDO were working fine and a phpinfo() check indeed confirmed I was on 5.3.8, but then several hours later a cron job died a fiery death:
[16-Dec-2011 03:00:01] PHP Warning: PHP Startup: Unable to load dynamic library '/opt/php53/lib/php/extensions/no-debug-non-zts-20090626/pdo.so' - /opt/php53/lib/php/extensions/no-debug-non-zts-20090626/pdo.so: undefined symbol: gc_remove_zval_from_buffer in Unknown on line 0
and the error log from the cron job directory:
[16-Dec-2011 03:00:01] PHP Warning: require_once(../pghqClasses/PDO.php) [function.require-once]: failed to open stream: No such file or directory in /home/XXXXXX/pghqIncs/initCron.php on line 19
So once again the PDO calls were failing, but this time only for cron jobs.
The support team's final reply was:
I've seen this behavior before, where relative paths in PHP scripts don't point to the right place. According to the PHP manual, one if the differences between the CLI php and other interfaces for PHP is that CLI PHP won't change directories to that of the script. http://www.php.net/manual/en/features.commandline.differences.php
To fix this, I've added the line:
chdir( dirname ( FILE ) );
to the top of your cron script so that, when executed, it WILL change directories to that of the script, therefore making the relative path work. When run from the website, this line will essentially do nothing, but it should make your cronjob run correctly.
And it does indeed work. My cron jobs are running smoothly, and my main site is good, and everyone is happily on 5.3.8, but that last bit of trouble-shooting totally lost me and I'd like someone to explain to me how the includes can fail for a cron but NOT for a public_html script, why we're chdir(), and so on?
Thank you, and sorry about the length...
The problem is that the cron job, which uses the command-line PHP executable is running with the current directory as the location of the PHP executable, or the home folder of whichever account is running the job. Therefore, any relative paths in the script are resolved relative to that location, rather than the directory containing the script.
By adding the the chdir() call you're setting the current directory to the location expected by the script, and therefore your relative paths resolve correctly.
Okay, I've tried everything, this is by far the best place it seems, I want to make Document Root here httpdocs/[folder]/html and I have php include files that I want to go above the root (require '../[folder]/file.php'] but not be able to access further than /var/www/vhosts/example.com/httpdocs. I know I'm being limited by open_basedir because the value is still httpdocs/[folder]/html in phpinfo() but for the life of me I can't change that local value!
This is what I've tried so far:
I've seen this - How to include file outside document root? - and created a 'vhost.conf' that is stil sitting in the conf directory, reconfigured the file, restarted apache...nothing. It's a good post but it seems a little out of date.
I edited php.ini itself to open_basedir = '/var/www/vhosts/example.com/httpdocs, uploaded it back up to where it was, reconfigured, restarted - nothing
I pulled out 'httpd.conf' edited it by adding the same lines from the other conf file,(vhost.conf), put it back in - nothing, I then tried to do what godaddy says here - http://help.godaddy.com/article/1616 and added the line php_admin_value open_basedir none' to 'httpd.conf - with no luck either.
It is now 0435 and I can barely keep my eyes open - this site is suppose to launch tomorrow at 2000! Thanks in advance to anyone who is willing/able to read and/or help.
Update: Thanks for a quick response, here are the best answers I can give you:
Does it give you an error?
Yes, I get a server error and through my server error log, specifically:
PHP Warning: require() [function.require]: open_basedir restriction in effect. File(/var/www/vhosts/[example.com]/httpdocs/[folder]/[folder where secure php files exist]/[file.php]) is not within the allowed path(s):
So I'm 99.99% sure its because of the open_basedir restriction.
Are you sure that your webserver is set as the owner of vhosts/ ?
I'm pretty sure, I'm kinda new to controlling servers and I don't really know what that means exactly but I have a virtual dedicated server through Godaddy, running Parallels Plesk v10.3.1, I did the above file moving going through Shell SSH.
In Plesk, I can change the 'Document root' to anything below /var/www/vhosts/example.com and Plesk will change the 'open_basedir' to anything I set. For example, If I set the document root to 'httpdocs' in Plesk then 'open_basedir' is changed to the same folder and everything works fine. The problem is I don't want public access to everything in /httpdocs/[folder]
My goal is I want to change 'document root' to /httpdocs/[folder]/html and 'open_basedir to /httpdocs but I can't change that local value in open_basedir for some reason. I want to do this for security purposes so people can only directly access the non important php files, but php itself I want to give more access to folders.
Are you trying to include using relative or absolute paths?
My paths in the php file that I'm trying to include/require to files above 'document root' looks exactly like this format:
require '../[folder where secure php files exist]/file.php';
If I'm understanding you correctly, I'm not using the entire path of the server.
ANSWER: (This was changed to the answer):
Apparently, in Plesk 10, Plesk's program sets whatever the 'document root' path will be, to the 'open_basedir' BUT there is no user friendly way to change 'open_basedir' in Plesk 10!!!
So instead it is a little bit of a hack, you have to first go here:
/usr/local/psa/admin/conf/templates/default/service/php.php
Then change both of these lines in the file, (line 11 and 29):
echo "php_admin_value open_basedir {$OPT['dir']}/:/tmp/\n";
to this:
echo "php_admin_value open_basedir /var/www/vhosts/[your.domain]/httpdocs/:/tmp/\n";
or to wherever you want the restriction to stop.
Then make sure your run these lines is SSH:
/usr/local/psa/admin/sbin/httpdmng --reconfigure-all
/etc/init.d/httpd stop
/etc/init.d/httpd start
But I'm having a new problem now. The 'document root' is pointing to the correct folder:
/var/www/vhosts/[my.domain]/httpdocs/[folder]/html
without any error however when the server gets to a:
require '../[folder]/[file.php]';
It skips through it like its not even there! Not giving me an error msg or anything. It's also skipping all my embedded css files, js files, images, videos...its not going to any of the directories! I have a feeling it's a 'php.ini' setting or something weird that Plesk is doing.
Solved: The last issue was because I never worked with accessing files above the root. PHP is allowed to go above the root but you can't do this:
src="../img/imagefile.jpg"
in HTML.
So after restructuring all my site files my website is now up and running! Thanks to all that helped, hopefully someone won't have to do that again. Also, I saw a post where Plesk is updating this because it is a big issue. Someone who works for Parallels said, http://forum.parallels.com/showthread.php?t=113236 this will be an option in the next version, so until then it's hack time!!
I cannot for the life of me figure out why my CodeIgniter install is not loading. I'm sure all my config files are correct, I even have error_reporting(E_ALL) and ini_set('display_errors', 1); set.
No matter what, I get a blank page.
In my error logs I found this:
[Wed Apr 27 11:08:15 2011] [error]
[client 127.0.0.1] PHP Fatal error:
Call to undefined function base_url()
in
/var/www/html/system/libraries/Loader.php
on line 255
Has anyone seen this error?
Line 255 is:
$CI->dbutil =& new $class();
Where $class is
$class = 'CI_DB_'.$CI->db->dbdriver.'_utility';
and $CI->db->dbdriver is 'mysqli'.
I used grep, and couldn't find a call to base_url anywhere in the Loader class or Database class.
EDIT: After changing some files (including the .htaccess file) and then changing them back, I got a different error:
The URI you submitted has disallowed
characters.
EDIT 2: Going to http://myurl.com gives a blank page, but http://myurl.com/controller gives the "disallowed "characters error.
EDIT 3: Apache was running as the wrong user, and my DB settings were wrong. After fixing those, the site works, but only if $config['permitted_uri_chars'] is blank. Otherwise I get the "disallowed "characters error.
UPDATE: Solved the issue! This new server has PHP 5.3, and the other servers have 5.2. preg_quote is different in 5.3, so I had to fix it by following the instructions here: http://davidmichaelthompson.com/2009/09/03/fixed-the-uri-you-submitted-has-disallowed-characters-error-codeigniter/
Is it a permissions issue over any of the CI library files?
chown www-data system -R maybe? Or 777 it just for testing?
The solution here was:
Apache was running as the wrong user, and had bad permissions on CI's files
PHP 5.3 has a different preg_quote than 5.2, the fix is here: http://davidmichaelthompson.com/2009/09/03/fixed-the-uri-you-submitted-has-disallowed-characters-error-codeigniter/
Make sure your DB settings are correct
I was having same problem, i installed latest xamp version and found my site is not working, after research and wasting time i found that.
I need to turn on following tag in php.ini file
short_open_tag=On
Make sure to restart apache after doing this.
Hope this helps, most of these problems are related to php.ini file or fresh installation if your site was already running as other people facing similar issue.
sounds like a syntax error.. check if all files are uploaded completely
Check your base_url in your config.php (in application/config/). Sounds like the syntax might be messed up or there isn't one defined.
$config['base_url'] = 'http://your_url/';
Also:
Which version of CI are you on? I just loaded up my loader.php file in my working project and my line 255 is a bit different than yours. $CI->dbutil =& instantiate_class(new $class());.. I'm not sure if that is relevant as I don't poke around much in the system folder but it is worth looking at
You can replace in your autoload.php file with following.
$autoload['helper'] = array('url');
I've just installed LAMP on my Ubuntu 9.10 machine, and everything works fine except when I copy my PHP files from another computer.
The LAMP guides I've followed also made me create a phpinfo() test file, which works, but when I try to type in e.g. index.php absolutely nothing happens - just a blank page in FireFox. :(
The files are in the exact same directory.
I'm thinking it's probably something with permissions and so on, but since I'm new to both PHP and Ubuntu, I'm kind of lost. It's like I can't create a PHP file with my file browser, but only by using the terminal - like when I created the testing.php from the LAMP guide.
Whaddayaknow... I made an error, tried to:
echo "Hello" world
which, even though I'm a PHP noob, I clearly know is wrong.
I think I'll have to figure out how to enable some sort of error reporting, a blank page is clearly not good enough.
You mean you have a index.php (copied from another computer) and a test.php (edited by hand, with a call to phpinfo()) in the same apache directory, the second works from your browser and the first doesnt ?
That can be a permission issue, or some compilation error in your php.
About permissions, for files should be readable from the apache server (more precisely, form the user that runs the apache server). You can type chmod a+r index.php.
YOu can also check your apache error logs (location dependent on installation). In any case it's vital to know where the error logs are if your are developing a web site.