Re^2: LAMP and hosting: Convenient Perl solution, similar to PHP setup?

[Burak]

You're suggesting a module from 10 years ago (latest release: 10 Jul 1998). I don't think it's suitable and in fact it looks like abandonware. And also mod_perl & mod_php do not work in the same way and since mod_perl can access Apache's internals, it is not suitable for sharad hosting AFAIK. I remember reading something about adding a less powerful (but suitable for shared hosting) mode of mod_perl but I don't think it happened yet.

I suggest FastCGI if you're on LAMP and PerlEx (this became some sort of freeware and is bundled with ActivePerl, I'm not sure if it has limitations though) if you're under IIS. PerlEx also has some embedded template support (like ASP) too.

[perrin]

Not true, there is no security issue with mod_perl that FastCGI doesn't also have. The biggest problems with running mod_perl on shared hosting are the need to restart apache to pick up module changes (there are workarounds like Apache::Reload) and the memory used, which is also the same as FastCGI. Nothing wrong with FastCGI though, and it does solve the restart issue if set up properly.

[Fletch]

Erm, FastCGI sets up persistent external processes; mod_perl allows you to execute code that calls (pretty much) any part of the Apache C API as well as muck with the perl interpreter state (of the particular child you're called from, but with that caveat complete access; just think of the mischief a malicious user could do rewriting other users' Apache::Registry-derived code). Also FastCGI processes can be run as completely separate users (via suexec), mod_perl code runs as the httpd user.

Just those two things alone present some serious security implications in a multiuser situation (which is why you usually see suexec'd FastCGI used in shared hosting situations, and mod_perl when it's running your own iron).

(Disclaimer: I haven't mucked with Apache 2 / m_p 2 sufficiently, but I don't believe they changed enough to eliminate the above issues.)

[perrin]

You can't modify apache's global configuration from within a request. People sometimes ask for this, but it can't be done with the way apache is structured. All that you can affect through the apache API is your own request, just like in FastCGI.

How would FastCGI prevent mucking with the perl interpreter? In both cases, the interpreter is persistent and perl will not prevent you from changing things that affect future code in the same interpreter.

Running as suexec would make a difference. The equivalent mod_perl setup would be to run a separate mod_perl backend for each user, which I've done in dev environments but it's annoying to set up. The security would then be identical, but it would use more memory than a shared server, just like suexec FastCGI would. In both cases the lack of sharing from copy-on-write is costly.

[xorl]

Once you've achieved perfection you don't need any more releases. ;-)

I've personally found ePerl to be great. While I prefer PHP now for any web work, ePerl gives perl the same ability as PHP to be included in webpages.

You can also check out embperl, which is something newer and may be more to your liking.

[bart]

But it's not that property of PHP that he's jealous of. Quite the contrary: for most serious web developers, that's one of the things you really ought to avoid.

What he wants is the other properties of PHP, like easy application deployment: for example, just drop in an archive for a Perl web application and just have it work. And proper separation of applications, so that they don't ever interfere with each other: neither by accident, nor on purpose (not everybody is trustworthy).

Those are problems for which neither ePerl nor embperl offer a solution.