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

[bramble]

I'm seeing a number of smallish (not terribly high-traffic) ecom sites written in PHP running in a shared hosting arrangement. Some of these sites are decrepit and could possibly use a rewrite, and it might be nice to use Perl for that. But, the argument I see coming from the old PHP guard (ex. current site maintainers and management) is that there's no way to do in Perl what you can so conveniently do in PHP, which is, you can just drop in a .php file and have it automatically run when a user accesses that page.

Is there a way to make Perl as convenient as PHP in that regard?

Note, I realize that high-powered LAMP-based sites will almost certainly be running on dedicated servers using mod_perl. But there is a lot of shared hosting out there, and a lot of smaller sites that don't need their very own server, and a lot of people who've seen how darn convenient PHP is (with regard to just dropping a php file in place -- not necessarily the language itself).

Perhaps what I'm really asking is, what's the easiest way to get a *fast* (i.e. persistent) Perl webapp running when you *don't* want the expense of (and responsibility for) dedicated hardware?

[perrin]

Shared servers suck. They are totally frustrating to work with. My advice is to get a virtual server instead, i.e. something where you get your own virtual machine with root. Those accounts are usually inexpensive.

As for dropping files in place like PHP, many popular perl systems like Mason follow the same approach.

[bramble]

Was not familiar with virtual servers. Are you referring to Xen maybe? Any other general info on them you could provide here might be useful to have in this thread. For example:

• How much admininistration is generally required? Do I usually get Apache2/mod_perl2 by default?
• What software is the provider using to create these virtual servers?
• Any recommendations on virtul server hosting providers?

[stiller]

Take a look at www.nearlyfreespeech.net for a very nice setup and price model. I use them for a couple of small sites.

[tonto]

Virtual private servers - I use Fluidhosting; there's a good explanation of VPS on their site and I'm very pleased with their service. One caution, some hosting plans that are advertised as VPS are really just shared hosting.

[Errto]

My understanding is that with a virtual server you can more or less run whatever software you want. Your costs are generally based on network, storage, and CPU utilization. An interesting offering in this area that caught my attention is Amazon EC2, but I haven't used it myself.

[bramble]

Shared servers suck.

I've had pretty good experiences with shared hosting, as long as the server is running GNU/Linux, I can ssh in, and all I need is CGI. The problem comes in when CGI is no longer fast enough. At that point, I remember that the hosting provider has mod_php and wish there was a "Perl-equivalent" for it.

[Rhandom]

If they have mod_php you probably don't want to host with them. mod_php is also susceptible to compromise. Most likely they are using fastcgi to run their php or using a php bytecode caching mechanism.

[perrin]

Are you sure they have mod_php? Many shared hosts run PHP as CGI because they don't trust the security of mod_php in a shared environment.

[sundialsvc4]

You've pointed to the old "issue" of ... “which came first, the webapp or the page?”

One school of thought (and by the way, such schools-of-thought exist in both the PHP and the Perl camps) says that you should always let Apache do what Apache does... serve-up a page, given its name. During the course of “serving up the page,” Apache discovers that the page contains executable code that it should run. That's the page centered approach.

The other school of thought argues that this is much too limiting, citing obvious examples such as “RESTful-ness,” in which the URI is taken to be the identifier of a resource that is not necessarily equivalent to a file. A single program intercepts all calls to the entire site, or to an entire region of it, evaluates the URI as one of its inputs, and by some means generates the appropriate response.

I find myself agreeing with the second point-of-view.

Going back to your final question, it's not at all difficult to get a Perl webapp running under shared-hosting. Simply make sure that your host is running a fairly-current version of Perl. Choose a convenient web-application framework in Perl, and set it up as per its instructions ... which no doubt will include very-specific guidelines for a shared hosting environment. Anything from Catalyst to CGI::Application can be pressed into service, and that's just with Perl.

You will undoubtedly find yourself setting up a local-to-yourself directory for the installation of CPAN modules, and module-versions, that are necessarily different from whatever the shared-hosting company has installed. It's easy to do; I've written on this topic myself here.

And then, just relax and dive in. No matter what approach you finally choose, it's going to feel weird the first few times you try it. Nothing to do with you, or with your site, or with the tool, or with Perl or PHP, your shared-host, or the phase of the moon. (Well, maybe the phase of the moon...) Just expect it, and move on. That's why it's usually best to set up a replica environment on your local servers, or even your own box, so that you can bash your head against the wall in quiet and peace. As you figure things out, keep a diary and take very careful, detailed notes ... because you will forget what you did and how you did it.

P.S.   For all the sites that I maintain, the authoritative copy is located on one of my servers, which is configured (as seen by this-or-that site) exactly like the appropriate host. Updating the site consists of tagging the files in the version-control system (to remember exactly what was “released today”), then using rsync to send the files up to the host. Testing is done locally, thanks to the /etc/hosts file and a slightly-different domain name (“.moc”), and I know that when the files go up to the shared-hosting site they will perform exactly the same as they do here. Work out such a system for yourself, document it (even for yourself), create checklists and procedures, and stick to them.

[kyle]

re "keep a diary"

I'd call that revision control. On the other hand, browsing around revision history and commit messages isn't nearly as easy as a file that you made specifically to record discoveries, even if it is likely far more detailed and accurate.

[sundialsvc4]

Project management systems can have “diary” capabilities, and if they exist they should be used. But a revision control system can only hold ... a revision. And by the time a “revision” has been created and checked-in... well, by then it's just too late. You “gone and done it.”

[Anonymous Monk]

... Choose a convenient web-application framework in Perl, and set it up as per its instructions ... which no doubt will include very-specific guidelines for a shared hosting environment.

So how would I run CGI::Application persistently in a shared hosting environment? I couldn't find any mention of "shared hosting" in its documentation.

[sundialsvc4]

I cautiously agree with the other Devotees that the information you are looking for is “out there,” even right-here on this site. (Some of it was written by yours-truly, for whatever better-or-worse that might mean.)

I also submit that you're going to encounter that requirement no matter what language or tool you are using. PHP may (or may not) be “the devil you know,” but you're going to have to do a certain amount of dancing with whatever devil comes to the dance.

To give you just a little bit more guidance as to where to look to find the missing-pieces, let me very briefly outline what some of the essential “missing pieces&rdquo will be (even if some of these are done for-you):

• You're going to be setting up a directory containing executable Perl programs, and those programs are going to include a use lib directive pointing to a local-to-you Perl-modules directory.
• You're going to use CPAN, when you're logged on to the shared host via ssh, to install those modules into that local place. Which means that you'll be doing some reading about how to do that with CPAN...
• You're going to use mod_rewrite rules, declared specific to your own virtual-host(s), which will transform incoming URIs and/or redirect them to your chosen Perl script.
• Since you are using a machine that you do not and cannot administer, you'll be making local changes and directing both Apache and Perl to refer to them with regard to your site.

Remember, none of this is “new.” (New to you, granted, but not new.) Even though your first impulse might be to go run screaming for the hills, it's actually just “four questions and no answers, yet.”

So, it's time to do some research. You're really going to need to surf-the-books for a day or two as the little lights come on. Keep a diary, in the form of a legal pad and a sharp number-two pencil. When you have a question or a “show stopper,” write it down and then let go of it so it doesn't “stop” you anymore. Gradually, and with increasing speed, the lights will come on and the question marks on your legal-pad will be overwritten with checkmarks.

“Then, a mere padewan you no more shall be. A guru you will have become...”   ;-)

[Anonymous Monk]

You consult the shared hosting environments documentation

[mr_mischief]

Some places run anything with a .cgi extension according to its shebang line. Others allow files with the executable bit set to run as CGI, or in any case files with certain extensions like .pl with executable bits set to do so. You're not likely to find mod_perl on shared hosting, though. You're also about as likely, if not more likely, to find Apache 1.3.3x as 2.x.x for that matter.

A small-to-medium local ISP is usually the easiest place to find shared hosting of a thoroughly modern bent. This is because they typically care enough about existing customers that they don't force incompatible upgrades across all their boxes. Then, when they build new servers, they try to get all the releases as recent as they trust to be stable so those new servers will be as close to current for as long as possible. Unfortunately, local ISPs are getting hard to find and you'll often be hosted on a single box with a single hard drive with some teenager at the helm. Keeping local backups is a good idea anyway, though. You also often have to wait until their old servers reach capacity and they're racking up more servers, as they won't put a new server up just randomly.

A VPS is definitely an option. Many of those by default still use Apache 1.3 as well, but you can find ones that use 2.x or you can upgrade it yourself (after all, it's your VPS). It's cheaper than any dedicated hardware server.

One thing people aren't entirely honest about with PHP is the idea that it's always mod_php. Often, especially on certain well-known bulk shared hosters, the PHP stuff is run as CGI scripts running as the owner of the content. That means that if you need a page's script to save data to your web space that you can do it with secure permissions, so that's a plus. It's not running within the Apache process, though, so you're not looking at the performance gain of doing that. Some hosting providers can give you choices in this regard, but some will just set you up the way everyone else is set up.

Not to pimp myself, but my partner and I sell hosting so I can give you some details and pricing for comparison if you like.

[TOD]

perhaps ePerl, and Parse::ePerl might be helpful for you. if you write a content handler based on these modules it should be achievable that users can just drop a page, and it will run.

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

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

[peterdragon]

Go for a root server, I can recommend either VPS at http://www.webfusion.co.uk/ or dedicated at www.1and1.co.uk.
They give you a Plesk control panel where you can set up mod_perl hosting. Or if you don't like that, you can bypass Plesk and set up your own Perl Apache config.

In terms of what you are asking for, a VPS or dedi host gives you pretty much what you want.

[lp]

I am also in that research right now... I tried a lot on my shared host, Dreamhost, which is great in terms of storage amount and lots more, but in any perl framework I wanted to try I always ended up not being able to compile some crucial modules... must be the 5.8.4 or something but it seems like a great host for PHP but no joy for perl... so insteat of trying to find a new host that would allow me to live my perl framework exploration, I choosed a new strategy: to do the exploration part of my developpement localy, in a virtual os inside VirtualBox, then I will know what it is exactly that I need in a host and will be a better shopper... maybe I'll discover I don't need root access or I'll find out its absolutely necessary.

[punkish]

Dreamhost, which is great in terms of storage amount and lots more, but in any perl framework I wanted to try I always ended up not being able to compile some crucial modules... must be the 5.8.4 or something but it seems like a great host for PHP but no joy for perl

Dreamhost allows you to compile your own perl and your own modules to your heart's content. I have done that on my $8 a month plan.