Atomicorp

Posted: **Wed Apr 20, 2011 6:30 am**

For years I have used a basic script that is still on PHP 4.3.9.

<?php
$fp = fopen('ticker/ticker.txt', 'w');
fwrite($fp, 'test test test');
fclose($fp);
?>

After working for years I have done something or something has done something. But I get nothing but:

Code: Select all

Warning: fopen(ticker/ticker.txt): failed to open stream: Permission denied in /var/www/vhosts/test.com/httpdocs/test.php on line 2

Warning: fwrite(): supplied argument is not a valid stream resource in /var/www/vhosts/test.com/httpdocs/test.php on line 3

Warning: fclose(): supplied argument is not a valid stream resource in /var/www/vhosts/test.com/httpdocs/test.php on line 4

I can run the command from the CLI just fine. But running it from the browser fails. It used to work fine! Safe mode = off. CHMOD 755 on the directory and 644 on the file.

Code: Select all

sh-3.00$ ls -lah
total 20K
drwxr-xr-x   2 test psacln  4.0K Apr 20 03:24 .
drwxr-x---  49 test psaserv 4.0K Apr 20 03:08 ..
-rw-r--r--   1 test psacln    84 Apr 20 02:36 test.php
-rw-r--r--   1 test psacln    14 Apr 20 03:24 test.txt

Posted: **Wed Apr 20, 2011 9:09 am**

My guess here is that the php is being invoked by the user apache, and that user doesn't have the permissions to write to tests directory. You can make the php invoke as the user test using either fcgi or the mod_ruid2 module. The other option would be to make the ticker directory owned by apache or change the permissions to be world writable.

Posted: **Wed Apr 20, 2011 1:42 pm**

This has worked for years. Now it doesn't. It will work as user apache but not account user anymore. I don't know how to do it with fcgi.

Posted: **Wed Apr 20, 2011 2:16 pm**

Of course it could be something else, but when I get these kinds of errors I usually check open_basedir/safe mode/paths and permissions problems.

In theory is *should* be a permissions problem as that's what the error is saying it is, but we all know that many error messages may as well be in Swahili or Zulu (for non-Swahili or Zulu speakers) in terms of the help they actually give when trying to track down a problem.

Talking of paths, have you tried an absolute path, like "/var/www/vhosts/domain.com/httpdocs/test/test.txt" or even a partial like "/test/test.txt" (is that the same place? Not feeling confeident about it) rather than "test/test.txt" ?

Posted: **Wed Apr 20, 2011 4:08 pm**

Nothing in the script has changed in years. I suspec a server setting. But I don't know where to look. Safe mode is off.

Posted: **Wed Apr 20, 2011 5:04 pm**

I simply don't understand. I can run the PHP script as a CRON but not from a PHP script. Nothing has changed. This script has been in use soince 2002. I had moved the site to another server and ended up moving it back. That's when the problem started -- I think.

Posted: **Wed Apr 20, 2011 6:40 pm**

faris wrote:Of course it could be something else, but when I get these kinds of errors I usually check open_basedir/safe mode/paths and permissions problems.

In theory is *should* be a permissions problem as that's what the error is saying it is, but we all know that many error messages may as well be in Swahili or Zulu (for non-Swahili or Zulu speakers) in terms of the help they actually give when trying to track down a problem.

Talking of paths, have you tried an absolute path, like "/var/www/vhosts/domain.com/httpdocs/test/test.txt" or even a partial like "/test/test.txt" (is that the same place? Not feeling confeident about it) rather than "test/test.txt" ?

Faris,

This has me completely baffled because I can run it as a CRON. But when I let the browser script run it based on a user action (it's a ticker-tape that updates often) I looked and the file was created and owned by root. I ran the CRON manually and it set ownership back to the web site superuser.

Posted: **Wed Apr 20, 2011 7:55 pm**

does the cron job run "php file.php" and as root? If so then the resulting file will be owned by root but readable by all, and so apache can read but not write to it.

Is if possible that the cron job is running in the background, and therefore has already created the file and so when the webscript tries to run it, as apache, it fails because it can't write to the file?

But then why would running the cron job manually (it is in the form of a shell script or what?) cause it to change the file's ownership to the right user when doing it via CRON itself fails to do so?

I'm as confused as you are! Sorry

Posted: **Wed Apr 20, 2011 8:00 pm**

This never used to be on a cron but is now running as a user cron on Plesk 8.6. It is working fine as a cron. I delete the file first and then pull the last 10 records from the database and write them to ticket.txt. This file is used on other sites showing our updates.

The part that doesn't make sense is that this used to be part of the script that is used to manually add the news item that 1) writes to the ticker, and 2) sends an email to subscribers. It just stopped working!

I don't like the cron approach because it doesn't solve the problem - the real problem. I like answers in life.

Posted: **Thu Apr 21, 2011 4:30 pm**

Hi,

Aren't there a number of problems here?

1) the ticker directory doesn't exist and it doesn't look like you're creating it, as it stands in your first post the lack of a directory would cause the problems you're having.
2) As Scott has said Apache can't write into the web root directory (You've said you moved this from one server to another, did you use the Plesk Migration Manager? If you did then any customised permissions you added to the httpdocs folder will NOT migrate, it defaults to 755 meaning on a Plesk 8.6 default install using mod_php you can't create files in the web root.)
3) It shouldn't work as a cron unless you have safe mode switched off for cron's or are switching it off on the command line (or using PHP 5.3 I guess).

Posted: **Thu Apr 21, 2011 4:46 pm**

Thank you for your input.

The error messages doesn't say that /ticker doesn't exist. It says that it cannot open it.

Code: Select all

drwxr-xr-x   2 nervous psacln  4.0K Apr 20 17:09 .
drwxr-x---  49 nervous psaserv 4.0K Apr 20 03:08 ..
-rw-r--r--   1 nervous psacln   117 Apr 20 17:08 test.php
-rw-r--r--   1 nervous psacln    24 Apr 20 17:09 test.txt
-rw-r--r--   1 nervous psacln   116 Apr 20 02:45 ticker.sav
-rw-r--r--   1 nervous psacln  1.4K Apr 21 13:35 ticker.txt
-rw-r--r--   1 nervous psacln  1.8K Apr 20 16:48 writeticker.php

This script has been running since 2002 without a problem. But now if I execute is from a browser it fails. I can get it to work but then the files are owned by Apache. I wasn't ware that one couldn't write to the webroot and that is good information. But it doesn't relate to this case. I used FTP to move the files to another server and never deleted them from this server. I changed back just by changing the NS records. The only time that it was ever migrated was when we moved from Ensim to Plesk years ago.

There were no special permissions. /ticker was chmod 0755 and ticker.txt was 0644. I fopen/fwrite 'w' creates the file if it doesn't exist in /ticker.

This process is working correctly as a cron with safe mode off. That's what doesn't make sense. I am wondering if mod_sec is doing something?

This is very, very frustrating because my anal intentive mind has to KNOW what I have done wrong!

Here is the entire codeblock that has worked all these years but now drives me bananas!

Code: Select all

function writeticker($database_sbnconnect, $sbnconnect) {
	mysql_select_db($database_sbnconnect, $sbnconnect);
	$query_recent = "SELECT datesent, timesent, sendernum, region, pagecode, agency, frequency, talkgroup, details FROM alerts ORDER BY datesent DESC, timesent DESC LIMIT 10";
	$recent = mysql_query($query_recent, $sbnconnect) or die(mysql_error());
	
	// write to ticker file
	$row_recent = mysql_fetch_assoc($recent);
	$FilePointer = fopen("ticker/ticker.txt", "w");
	do{
		$Data =  sprintf("%s | %s | %s | %s | %s | %s | %s | %s | %s",
		$row_recent['datesent'], $row_recent['timesent']." PT", $row_recent['region'], pagecode($row_recent['pagecode'], $database_sbnconnect, $sbnconnect),
		$row_recent['agency'], $row_recent['frequency'], $row_recent['talkgroup'], $row_recent['details'], $row_recent['sendernum']);
		$Data .= "\n";
		fwrite($FilePointer, $Data);
	} while($row_recent = mysql_fetch_assoc($recent));
	fclose($FilePointer);
	return;
}
// end function

Thanks again for the help from all of you. That's what I love about AT!

Posted: **Fri Apr 22, 2011 6:31 am**

stupid question. how does "disabled functions" in your php.ini look like?
Have you done any updates for php or mysql on this server?

Posted: **Fri Apr 22, 2011 1:31 pm**

if you have always been running the site as mod_php via apache (and not as cgi) then the first time you created the file it would have been owned by apache, which would then always have ownership and you wouldnt see the problem.

Its possible that if you created the file or did something in FTP that reset the ownership then suddenly apache no longer has access to write the file.

YOu could make it 666 permissions instead so that it will always be writable by the web server no matter what.

Posted: **Fri Apr 22, 2011 3:45 pm**

I can erase the file and the script will create it as the userid. I can D/L it and edit it, then send it back to the server as the same owner.

This is what has changed. Now if I delete the file it is. created by user apache. Keep in mind that no changes were made to the server. I simply FTP'd the site to another server and changed the NS records. I decided to keep it back on the original server and switched the NS back.

Something other than is the problem. Remember that I can run the script via SSH as the userid and it creates the file. It is only if the action originates at the browser. Mod_sec?

The CRON continues to work.

Posted: **Fri Apr 22, 2011 3:48 pm**

Thats the thing - moving to a different server your previous server probably ran PHP differently - either they used something like suphp or ruid2 that switched the php user to the FTP user instead of apache or it ran as a CGI - where as now its running mod_php under apache which runs as the user apache instead.

I would imagine that if you renamed the file to filename.old that if you then re-ran the script and it recreates under the correct user then you wont run into the permissions problem anymore since it will be owned by the "correct" user with permissions to write to the file.

Atomicorp

Unable to fopen/fwrite

Unable to fopen/fwrite

Re: Unable to fopen/fwrite

Re: Unable to fopen/fwrite

Re: Unable to fopen/fwrite

Re: Unable to fopen/fwrite

Re: Unable to fopen/fwrite

Re: Unable to fopen/fwrite

Re: Unable to fopen/fwrite

Re: Unable to fopen/fwrite

Re: Unable to fopen/fwrite

Re: Unable to fopen/fwrite

Re: Unable to fopen/fwrite

Re: Unable to fopen/fwrite

Re: Unable to fopen/fwrite

Re: Unable to fopen/fwrite