How to add Perl to Apache

I’ve been using Apache+php for several years and, as far as I remember, installing it was a breeze.

Now I want to add Perl for some number crunching so that I don’t have to run scripts from terminal all the time and I want the output to look nice and comprehensible, but can’t find a simple way to integrate it with Apache.

I added mod_perl to Apache, which created a basic mod_perl.conf file, and if I put a test.pl script into “/srv/www/cgi-bin/” it kind of serves (browser shows file content) but does not execute.

The same script located in my “public_html” is still offered as a download option.

There are tons of guides on Apache+Perl setup on the internet but they are all very long, start with building from sources, and everything must be done manually, carefully replacing generic package names and locations to user’s own OS setup.

Then there’s cgi scripts vs mod_perl issue.

I hope there’s an easier way.

What I want is inserting perl code in html pages just as it’s done with php, and I want to keep perl scripts in my website directory, not in /srv/www/cgi-bin/ where I can’t edit anything without root access. It would also be nice if I didn’t need to change permissions on every .pl script to executable, just as it’s done with php.

I hope it’s not too much to ask.

Stan Ice wrote:
> There are tons of guides on Apache+Perl setup on the internet but they
> are all very long, start with building from sources, and everything must
> be done manually, carefully replacing generic package names and
> locations to user’s own OS setup.

Well this is an official tutorial and it doesn’t do that:
http://httpd.apache.org/docs/2.2/howto/cgi.html

> Then there’s cgi scripts vs mod_perl issue.

Not really. The rule is simple - don’t use mod_perl.

For developing homebrew scripts, you’re best sticking with Apache and
putting your scripts in the cgi-bin directory. It’s simple,
well-documented and makes it easy to test changes to your code. Once you
get more experience, you can use some other method, but your experience
will tell you what suits you.

If you want to make a production website, where performance and
scalability matters, then that is the sort of problem mod_perl was
written to solve. But there are better solutions nowadays, such as
fastcgi, or other web servers. Again, you’ll come to know about them
when and if you get to understand the problems.

> I hope there’s an easier way.
>
> What I want is inserting perl code in html pages just as it’s done with
> php,

That’s not how perl works. Read up about perl and web programming before
going too much further. Be aware that many perl coders, myself included,
view PHP as a shambles.

> and I want to keep perl scripts in my website directory, not in
> /srv/www/cgi-bin/ where I can’t edit anything without root access. It
> would also be nice if I didn’t need to change permissions on every .pl
> script to executable, just as it’s done with php.

Again, stick with the standard ways of doing things until you’re sure
you understand why they are done that way as well as why you want to
change them.

If you don’t want to use the system-wide CGI directory, then set up one
in your home directory as described in the tutorial I linked.

> I hope it’s not too much to ask.

It’s the wrong question.

I’ve seen that tutorial, I’m a bit apprehensive about going through it on my own. It starts with modifying httpd.conf but httpd.conf that came with Apache says “# If possible, avoid changes to this file” and advises that “global settings that can/should be overridden in the configuration of your virtual hosts.” A few paragraphs down the tutorial asks to add all kinds of directives and stuff in the format that sometimes doesn’t look like anything already included in httpd.conf which, btw, appears to be completely commented out.

The link to http://en.opensuse.org/Apache_Quickstart_HOWTO mentioned in httpd.conf is not working.

Anyway, if thats the way to get Perl working I’ll try my best.

Is it safe to add all those directives to httpd.conf or should I find and configure my “virtual host” instead? Can I just create a new .conf file in /etc/apache2/conf.d/ for Apache to load all perl related “directives” and configuration?

Also, do I have to uninstall mod_perl or remove mod_perl.conf or somehow unload it from Apache?

Stan Ice wrote:
> I’ve seen that tutorial, I’m a bit apprehensive about going through it
> on my own. It starts with modifying httpd.conf but httpd.conf that came
> with Apache says “# If possible, avoid changes to this file” and
> advises that “global settings that can/should be overridden in the
> configuration of your virtual hosts.” A few paragraphs down the tutorial
> asks to add all kinds of directives and stuff in the format that
> sometimes doesn’t look like anything already included in httpd.conf
> which, btw, appears to be completely commented out.

Yes, you uncomment things that you want to use.

> The link to http://en.opensuse.org/Apache_Quickstart_HOWTO mentioned in
> httpd.conf is not working.
>
> Anyway, if thats the way to get Perl working I’ll try my best.
>
> Is it safe to add all those directives to httpd.conf or should I find
> and configure my “virtual host” instead? Can I just create a new .conf
> file in /etc/apache2/conf.d/ for Apache to load all perl related
> “directives” and configuration?

I’ve never bothered with virtual hosts. Other people using nothing but.
There is a Perl aphorism - TIMTOWTDI - and it can be scary at first.

You can just add extra files in conf.d, yes, and I do that sometimes, so
it is easy to enable and disable particular things. But then you have to
manage the interactions between different files and you have to remember
where you’ve put stuff. So if you’re just starting out, I personally
would keep it all together so you can see it all.

Make one change at a time and keep backups. Restart apache after every
change so you can check it has had the effect you wanted

> Also, do I have to uninstall mod_perl or remove mod_perl.conf or
> somehow unload it from Apache?

No, it will just sit there quietly. I’m sure it’s possible to remove it,
but you’ll need to ask somebody else how.