Simon Wilcox wrote: > mod_perl is a security nightmare in a shared environment which is why you > will need to go the dedicated route.
I haven't had a need for mod_perl in a shared hosting environment, but before recommending my favorite shared hosting provider that I use with clients, I figured I check what their mod_perl policy was: https://panel.dreamhost.com/kbase/index.cgi?area=2446&keyword=mod_perl We do not support mod_perl on our shared hosting plans. We do support mod_perl on our dedicated servers though! We're sorry about this. There are several problems with allowing mod_perl in our shared hosting environment. mod_perl can hog too much memory if code isn't properly written. It has the potential to introduce a great deal of instability to our systems. We are not anti mod_perl - we use it extensively in our own web panel, however we don't feel that supporting it in a shared environment is scalable. We are looking into ways to provide mod_perl with our shared hosting offerings in the future, but do not currently have a time line in place. No wonder we're getting killed by PHP. Customer comments to the above included a pointer to a discussion on this topic: http://aspn.activestate.com/ASPN/Mail/Message/modperl/2167178 Some quotes of interest: http://aspn.activestate.com/ASPN/Mail/Message/modperl/2176383 ...in a shared hosting environment, especially a mostly automated one, we have very little control over customers' code. And, since we have (a lot) more than one customer on each instance of Apache, mod_perl allows customers to write code that will either prevent the Apache from starting at all, or even bring down an entire machine (hence the "instability" comment). Providing an entire instance of Apache for each mod_perl site isn't really feasible for us either. ... We used to support mod_perl on shared hosting plans; it caused too many problems for us. [authored by an employee of the ISP] http://aspn.activestate.com/ASPN/Mail/Message/modperl/2177506 Explain the success of PHP then. Apparently the cross-site holes were tolerable for long enough... http://aspn.activestate.com/ASPN/Mail/Message/modperl/2167271 Err, do they have PHP? Its more of a memory/resource hog and is more unstable, assuming the same task and similar programming technique. (I make this statement as someone who has to rebuild at least one apache per day due to PHP problems and troubleshoot resource useage issues that usually go down to a badly written PHP scripts) http://aspn.activestate.com/ASPN/Mail/Message/modperl/2177500 What bothered me about your policy is that it accuses mod_perl of these things, and yet you offer PHP as an apache module. PHP has plenty of security issues when you don't run it as CGI, and you can certainly crash the server with it. Correct me if I'm wrong, but the understanding I've had of mod_perl is that it allows you to access Apache's internal API to pretty much the same extent as a native C module does, and thus allows you to create new modules written in Perl, while the more recent mod_<language> modules for other languages don't allow quite the same level of access. I've often wondered if this greater power in mod_perl has been a hindrance rather than a help to the Perl web development community. Would we have been better off if, in addition to mod_perl (for the rare cases when you do need low-level access), there was a mod_perl_embed, or something like that, that was restricted in ability and focused on the needs of the typical site developer? Back to the original question, the thread also included: http://aspn.activestate.com/ASPN/Mail/Message/modperl/2167518 Gossamer-Threads has a pretty cool mod_perl setup. You can get a dedicated server or a shared account. Each shared account has its own apache process, which means that you can log in and control (i.e. stop / start / restart) your own modperl httpd. And a pointer to: http://perl.apache.org/help/isps.html which lists ISPs Supporting mod_perl. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
