PHP Configuration

Same here. What i am missing most is configuring php error log, i am totally confused that such an important thing is turned OFF by default.

On ispCP i changed the template file so each domain got its log unter its "logs" subdirectory.

On iMSCP this doesn't work anymore because the domain's log dir is now owned by root, but php runs under vuXXXX. I tried to put it under domain root folder then but there is simply happening nothing. It may be a permission thingy i don't know yet. I saw there is some php error printing within the apache? error log but that is not enough. Think about call traces that are printed or even more using XDEBUG.

Of course if a new log is added, it should be part of rotation as well

I saw there are listener files for pool config override but that's too static and unsexy. I also don't know a good error log store location yet because of that root-thingy.

Quote from itscz.org

On iMSCP this doesn't work anymore because the domain's log dir is now owned by root, but php runs under vuXXXX

There is a reason for that. The log directory you're talking about is reserved to Apache logs. Apache log directories are bind mounted..

Quote from itscz.org

I tried to put it under domain root folder then but there is simply happening nothing. It may be a permission thingy i don't know yet.

The customer's home directory (what you calll root folder) is protected by default (using immutable bit) to prevent the customer to deleted default folders.

Quote from itscz.org

Of course if a new log is added, it should be part of rotation as well

We will never enable PHP log by default. On production server where there is several hosted PHP applications, enabling PHP logs slow down the server.

Quote from itscz.org

I saw there are listener files for pool config override but that's too static and unsexy. I also don't know a good error log store location yet because of that root-thingy.

The listener is easy to use. You can change PHP parameter as a per domain basis... You can always store the PHP log into a subdirectory of your htdocs and disallow access to that directory.

Quote from Nuxwin

We will never enable PHP log by default. On production server where there is several hosted PHP applications, enabling PHP logs slow down the server.

I didn't want it on as default too, but it would be nice to enable it per domain/site or whatever is my pool config. The little gain of speed will not help me in supporting customers to find bugs or misconfigurations

Quote from Nuxwin

The customer's home directory (what you calll root folder) is protected by default (using immutable bit) to prevent the customer to deleted default folders.

Thank, i'll deal with it. Placing in htdocs is not a good idea, best would be "logs" as the name says but it's blocked, but i'll find a place...

Use the private directory

IMHO it would be really at time to re-think the constraints of memory_limit, post_max_size and upload_max_filesize defined in PHPini.php

There is a comment saying "According PHP doc, post_max_size value *must* be lower than memory_limit value"

The truth is:
http://php.net/manual/en/ini.core.php#ini.post-max-size
"Generally speaking, memory_limit *should* be larger than post_max_size."

Notice the difference between *must* and *should*, good reading about is here
https://www.ietf.org/rfc/rfc2119.txt

There are enough cases where uploaded data is not processed by php, and there is no need to have a ridiculous high memory_limit just to accept large fileuploads.

i.e. upload of images that are processed via cli-tools and not within the http-request.

@_alex

The parameters set through the PHP Editor doesn't affect CLI SAPI. So yes, you're right about *shoud* vs *must* but nothing prevent you to set the upload_max_filesize to a low value. In the PHP editor, you can have

memory_limit: 32
post_max_size: 16
upload_max_filesize: 2

Thus, I don't really see the problem here...

Of course, I can remove the constraints but in that case, customer will have to pay attention.

Quote from Nuxwin

@_alex

The parameters set through the PHP Editor doesn't affect CLI SAPI. So yes, you're right about *shoud* vs *must* but nothing prevent you to set the upload_max_filesize to a low value. In the PHP editor, you can have

memory_limit: 32
post_max_size: 16
upload_max_filesize: 2

Thus, I don't really see the problem here...

Of course, I can remove the constraints but in that case, customer will have to pay attention.

Display More

Hi Laurent,

well, but what if it's the other way round ?

I want to accept files up to 200Mb in Size (PDF's, doing checks with poppler utils, create thumbnails with ghostcript and what not).

My php-app is fine with 64mb memory_limit,
so reasonable settings are:

memory_limit 64
post_max_size 200
upload_max_file_size 200

What happens is that i'm forced to set memory_limit > 200mb by imscp, what imho is absolutely not necessary ...

Other use-case would be collecting video-uploads with php, then process with ffmpeg.
Here it could end that memory_limit needs to be in the size of several gigabytes.
Just to move the files with move_uploaded_file somewhere a cron catches up for processing.

I appreciate the poll, but wouldn't a third option 'make it configurable if imscp forces them' make sense ?

btw., as memory consumed by gd is accounted into memory_limit these settings absolutely don't keep people from running out of memory / into memory_limit, even when processing uploaded images much smaller than memory_limit ...

@Alex

I'll release the memory_limit constraint For any other talk please create your own thread.

Thanks.

Hi Nuxwin,
thanks - hacked them pretty ugly what broke with every update but more worse messed-up things after i edited reseller-props limits of the reseller's domains were reset to defaults (this maybe is another topic / won't happen anymore when released).