Forums / Install & configuration / memory_limit set to 8M in php.ini

memory_limit set to 8M in php.ini

Author Message

Peter Schroeder

Wednesday 11 February 2004 9:01:21 am

My web host's php.ini has the memory_limit set to 8M and he is not willing to change this. He told me to place a changed copy of php.ini in every folder a php script gets executed from (would that be the "local copy"?) Is there a better way to solve this than having to put a copy of php.ini into every folder with php scripts? Anyone done this before?

Marco Zinn

Saturday 14 February 2004 2:53:05 am

Hi, well, i am surprised, that you can override the setting of php.ini with this procedure... but it's a similar approach like placing .htaccess files into directories, so maybe it will work.

Now, the good news for you: ezPublish ALWAYS executes the index.php, which is in the "top level" folder. So, it should be enough to place the php.ini there.
I don't know, if the ezPublish installer checks for the memory_limit setting. If it does NOT do this, you should verify, if this procedure (overriding the setting with a copy of php.ini) works, before you install ezPublish.

Marco
http://www.hyperroad-design.com

andrew hobbs

Sunday 14 March 2004 8:11:11 am

You can set this in PHP code...

ini_set ( string varname, string newvalue)

or in the .htaccess file...

php_value name value

andrew hobbs

Sunday 14 March 2004 3:06:28 pm

Here's the actual line to put in .htaccess...

php_value memory_limit "12M"

Peter Schroeder

Monday 15 March 2004 12:17:10 pm

Andrew,

if I put this statement in my .htaccess file I get the 500 "Internal Server
Error" message. After I checked the error log I saw the entry
".../home/ensanch/public_html/.htaccess: Invalid command 'php_value',
perhaps mis-spelled or defined by a module not included in the server
configuration".

Peter

andrew hobbs

Monday 15 March 2004 3:17:03 pm

According to http://www.phpfreaks.com/tutorials/110/0.php this maybe a syntax error.

It may be an issue with how PHP is installed on your server.

Iain MacLean

Monday 15 March 2004 6:27:08 pm

Hi

I think the syntax error is caused by the quote marks around the 12M in the .htaccess file. It should work without them.

Alternatively, you can put

ini_set ( memory_limit, "12M" );

in the first line of your index.php file after the commented-out header. I think you have to do this if you want to run the installation setup script to run again.

Regards

Iain

Peter Schroeder

Wednesday 17 March 2004 2:02:43 pm

It's none of the above. I just found out that my webhost uses phpsuexec for securuty and does not allow the AllowOverride Options in his httpd.conf file. This means php is executed as a CGI and not a module and chockes on php_value settings in a .htaccess file. That's the reason why I get the 500 internal server error message.

Peter Schroeder

Wednesday 17 March 2004 2:06:28 pm

Just in case some one is interested in a more detailed explanation of this, here is my webhost's explanation:
>>PHP - Important Info About PHP
We have recently added a security feature to our PHP/Apache setup called PHPSUEXEC. This may change how you use PHP on our web servers.

First off, for security, we want to run PHP with suEXEC. Why? Because that way scripts are executed under the username of the domain owner. This makes it easier to track what users are doing and emails that are sent. It also limits what they the user can modify and whether they can view session data in the /tmp folder. These are all important security considerations for a web host who has several customers on each web server.

The first thing you need to realize is that for PHP to use suEXEC, it must be run as a CGI. This is probably the most secure way of running PHP. This is in contrast to running it as a module (i.e. mod_php).

The problem with running php as a CGI is that it would require all PHP scripts to start with an opening spec (just like most UNIX scripts) saying what the interpreter to use is. For example, you would have to change ALL your PHP scripts to have the following first line:

code:--------------------------------------------------------------------------------
#!/usr/bin/php
--------------------------------------------------------------------------------

Now, this is a problem because we would then need to change ALL php scripts to have this first line. Of course, this would be out of the question for a web host, hosting many sites on many servers.

That's where phpsuexec comes in. It is nothing more than a module loaded into Apache that essentially prepends that line to PHP scripts so that you don't need to go and edit all of them. THIS IS THE MAGIC!.

Because PHPSUEXEC causes PHP to run as a binary now, and being suEXEC'd, the same rules apply as they do when you suEXEC any other cgi script. That is, the script must abide by the following rules:

1. User executing the wrapper must be a valid user on this system.
2. The command that the request wishes to execute must not contain a /.
3. The command being executed must reside under the user's web document root..
4. The current working directory must be a directory.
5. The current working directory must not be writable by group or other.
6. The command being executed cannot be a symbolic link.
7. The command being executed cannot be writable by group or other.
8. The command being executed cannot be a setuid or setgid program.
9. The target UID and GID must be a valid user and group on this system.
10. The target UID and GID to execute as, must match the UID and GID of the directory.
11. The target execution UID and GID must not be the privledged ID 0.
12. Group access list is set to NOGROUP and the command is executed.

One issue that our customers will have to contend with is php_value settings. Many customers "tweak" php settings in their site by using the .htaccess file located in their web directory. "php_value settings" in .htaccess files are only interpreted by the module version of PHP. The binary (cgi) version actually chokes on these and you get a Server 500 error. Thus, if you have added php_value settings to your .htaccess file, comment them out or remove them. Instead, you can use a file in your site called "php.ini" to create your value settings. php.ini will actually give you more control and more flexibility.

To sum up, PHP on our servers now use PHPSUEXEC.

1. PHPSUEXEC makes php run as a binary rather than a module. This gives us more security and helps us to track offenders (you would be suprised at how some customers abused our AUP before we added PHPSUEXEC!).

2. You will have more flexibility with tweaking how PHP behaves on your site by using php.ini in your web directory.

3. If you use mime types to make PHP parse as .html or .htm, you will need to use APACHE HANDLERS to do this instead. Login to your control panel, click on SERVERS and then click on APACHE HANDLERS.

4. There are certain restrictions on scripts that users must abide by. If your script stops working, read the 12 rules about PHPSUEXEC above.