Issue Change Options in PHP Setting Dropdowns

[treynolds_envalo]

I need to set the max_execution_time above 120 second. I have done this successfully with a workaround, but I would really prefer to make it simple for us to change our host environments using the dropdowns on the PHP settings panel.

Overview of the issue:
The 'max_execution_time' dropdown only has 4 options: 30, 60, 90, 120.

When you choose one of those options, Plesk automatically re-configures Apache and Nginx to set their Timeout and proxy_read_timeout values respectively.

You can enter in a PHP and Apache directive to override the 120 value, but you cannot for Nginx as it gives an error about a duplicate directive in the nginx configuration file.

The workaround is:
1. Edit the default php.ini file for the version of PHP we are using (5.6.36) to set the default max execution time. (I set it to 600)
2. Go to the PHP editor and click the 'use default value' link next to the max_execution_time dropdown, which will change the value to 600
3. Save the PHP settings, which now makes Plesk NOT put any directive for Timeout or proxy_read_timeout
4. Enter in the directives for Timeout and proxy_read_timeout on the Apache/Nginx page.

What I would have LIKED the system to do is use the value of 600 in the Apache and Nginx configuration files.

So my question is, how can I add more options to the max_execution_time dropdown? I've grepped all over the Plesk install hoping to find a configuration file that would drive those dropdowns. I have been unsuccessful.


Thank you

 

[IgorG]

So my question is, how can I add more options to the max_execution_time dropdown? I've grepped all over the Plesk install hoping to find a configuration file that would drive those dropdowns. I have been unsuccessful.

I suppose that it is hardcoded. You can submit corresponding feature request to Feature Suggestions (1770 ideas) – Your Ideas for Plesk
We will consider this feature request if it will become popular enough.

 

[trialotto]

@IgorG

I suppose that it is hardcoded.

I am pretty sure it is. And that is a good thing.

Any value above 120 is really bad practice, in the sense that it would imply a considerable augmentation of the security surface (in this case, the degree to which any attempt to attack the system can persist, which is very problematic if part of the attack is intended to overload web servers) AND in the sense that it would severily impact stability of the Plesk eco environment (in this case, the stability will be endangered by unnecessarily long processes that are certain to reduce the stability of Apache web server, this is irregardless of the chosen MPM).

If any possibility should exist to increase the duration of (worker) processes, it should also require an adjusted default Apache configuration, especially the configuration with respect to workers.

In short, it is good as it is right now.

 

[treynolds_envalo]

@IgorG



I am pretty sure it is. And that is a good thing.

Any value above 120 is really bad practice, in the sense that it would imply a considerable augmentation of the security surface (in this case, the degree to which any attempt to attack the system can persist, which is very problematic if part of the attack is intended to overload web servers) AND in the sense that it would severily impact stability of the Plesk eco environment (in this case, the stability will be endangered by unnecessarily long processes that are certain to reduce the stability of Apache web server, this is irregardless of the chosen MPM).

If any possibility should exist to increase the duration of (worker) processes, it should also require an adjusted default Apache configuration, especially the configuration with respect to workers.

In short, it is good as it is right now.

I disagree entirely.

My company hosts e-commerce environments for our clients. We don't need a time above 120 seconds for general use, but when a client wants to do a data load of 10k products then we should have the ability to do that.

A single long running process will have no impact on the stability of the Apache web server, or nginx. That's absurd and has no basis in reality. As well it won't have any impact on Plesk itself as it is just a frontend that configures and manages other services. Plesk being there is meaningless to operation of Apache and Nginx.

Nearly all front-end operations a customer could perform will finish in less than half a second on our sites, with a few that may take 1-3 seconds because of communicating with outside services. So, given that, the difference between 120 seconds and 600 seconds in irrelevant to the security and stability of an environment. What it isn't irrelevant to is the usability of the sites for our clients.

I'm just a bit offended at the 'I know better than you' attitude of your response.

 

[trialotto]

@treynolds_envalo

I can imagine your viewpoints and understand your arguments.

My company hosts e-commerce environments for our clients. We don't need a time above 120 seconds for general use, but when a client wants to do a data load of 10k products then we should have the ability to do that.

However, in the above you present a case (the upload of specific products) that is exactly an example of a reason why one should not want more than 120 seconds.

Anything exceptional should be dealt with tools that are made for that: ftp upload (images and other content files) and/or PhPMyAdmin (databases) and so on.

And an even better solution is to create one separate application for the purpose of bulk uploads: that one can have a time far above 120 seconds (everything els on default).

In your opinion, increasing the (execution) time considerably is a good solution.

In my opinion, increasing the (execution) time is a non-efficient work-around, due to the lack of a good solution that should already be present.

From your perspective, it is a good idea to allow customers to deliver huge payloads to the web server, with the danger of the entire server shutting down due to overloads.

From my perspective, it really is a bad idea to allow anyone else than the sysadmin to deliver risky payloads to any server.

Nearly all front-end operations a customer could perform will finish in less than half a second on our sites, with a few that may take 1-3 seconds because of communicating with outside services. So, given that, the difference between 120 seconds and 600 seconds in irrelevant to the security and stability of an environment. What it isn't irrelevant to is the usability of the sites for our clients.

A DDos attack or a similar type of attack will result in down time of your server, if you allow long execution times.

A bad script will run endlessly and can result in down time of your server, if you allow long execution times.

In the current world, most open source applications and associated plugins often contain badly formed scripts (have a look at your error logs for the average WP instance) AND a whole lot of attack scripts are scanning for php vulnerabilities, including long execution times, in order to send a never ending request (and enter via the backdoor).


In your opinion, security and stability are not at stake............so, for the sake of the argument, let's leave it at that.

But why increasing the (execution) time if your average cutomer or front-end operation does not even require an execution time of 30 seconds?!???

You should really think differently and also understand that increasing the (execution) time also implies that each worker is open during that long execution time, unless you do some fancy configuration that will bite you in the case that an actual lengthy request is being executed.

Sometimes it is just better to keep things simple: if you do not need it, do not use it.

In your own words, you do not need long (execution) times, due to the nature of average front-end operation.

I would really recommend to not increase the (execution) or enter Plesk's default scripts (which can be overwritten anytime).

But the decision is up to you.

Regards............