I’m not sure that we can, and I’m even less sure that we should. Three thoughts come immediately to mind, and I guess they aren’t particularly encouraging:
- The process of using a custom php.ini with a copy of DH’s stock PHP installation to increase the maximum execution time (as described in the DH wiki) is about as simple as it can be made. I suppose that a special section dedicated to changing that item alone, in the context of the rest of the article might make it somewhat easier, but it would still require access, and machination in, the shell (which is probably the “deal breaker” for many users).
Even if that was done, and users could be persuaded to attempt it, they would be “on their own” as DH does not support such modifications - you use them at your own risk and to your own detriment if you “bork” it.
- That maximum_execution_time setting is set the way it is to help make sure that scripts running on shared servers “play well with others” on a shared server. It would be different if increasing execution time only impacted a given site’s responsiveness, but the reality is that allowing increased execution time on a shard server can result in seriously degraded performance for all on the machine - even more so if numerous users do this.
I suspect that the the “barrier to implementation” you describe, and the expertise of the resultant “few” who do this, are one of the reasons DH continues to allows us to do it. The occasional user doing this, intelligently, might not present much of an additional load on the server but, if everyone (or a large number of people) did this, I suspect DH would have to step in and disallow such customizations in order to keep the servers from being loaded to death.
- All that said, at some point increasing max_execution_time, and max_memory, etc. for use on a shared server is not likely to be much of a real “fix”. The truth is, in the interest of self-preservation, the DreamHost systems’ “procwatch” program(s) will eventually kill programs running longer, taking more memory, or using more CPU resources than DH deems to be appropriate irrespective of those php.ini settings.
This may be unfortunate for those trying to get the most “bang for the buck” out of shared hosting, but it accurately reflects the fact that some stuff just is not appropriately run on a shared server. Maybe CiviCRM fits that description, and maybe it doesn’t; I’m sure opinions on that vary.
Scripts with particularly heavy CPU, memory, and/or execution time requirements are probably better suited for a dedicated server (or at least a DH PS system). “You can only pack so much stuff into a Cooper-Mini”
Of course, how “much” is “too much” (what defines “particularly heavy requirements”?) is a relative thing. DreamHost has pretty much indicated how they feel about that (as well as certain security related characteristics of PHP) with their default PHP settings and, while they allow us to “workaround” some of those settings, we still have to make certain that our actions don’t negatively impact others if we choose to do so.
To my thinking, making it “easier” for users, particularly those with insufficient knowledge of what is involved (as possibly indicated by their inability to accomplish the modification?), is probably detrimental to everyone on their shared server, so I’m not particularly anxious to facilitate that. That doesn’t make me “happy” about it; it just reflects the reality of the situation.
Finally, where do you draw the line? How easy do any of us on shared servers really want it to be for a user to enable register_globals, allow_url_fopen, etc. in order for them to run some unvetted/old/possibly insecure script?
I’m not saying that is the case in running CiviCRM (which I see as more of a resource issue than a security issue), but I think the principle issue, that of facilitating custom modification of an environment running on a shared server, is the same and encompasses some of the same concerns - primarily the experience of other users on the server.