PHP Configuration

  • It would be awesome to have a little more control on configuration of php.ini per user in their control panel via a GUI interface. Making it as highly configurable as would allow like changing openbase url, post_allows, etc. I know it has security risks invovled, but I started doing my own hosting because of the lack of control I could get out of my hosting provider.


    Maybe this could be a paid plugin situation. I know I would pay for that and it could be another paid plugin to help development costs.


    I thank you and keep up the great work ... :)

    “Life is all an Elaborate Hoax”

  • 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.

  • 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..


    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.


    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.


    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.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • 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 :)


    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...

  • 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.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • 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.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • 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).