Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Perl/mod_perl on shared web servers

by trs80 (Priest)
on Feb 14, 2002 at 04:01 UTC ( #145367=perlmeditation: print w/replies, xml ) Need Help??

I was recently asked to move an Apache::ASP site from a dedicated non Verio server to a shared server at Verio. The site was installed on a Linux Red Hat 7.0 box with a static (non DSO) compile of httpd with mod_perl. (Apache 1.3.22 and mod_perl 1.26)

At first I thought the install on the ViaVerio server wouldn't be too difficult, boy was I wrong. There were several things that seemed to effect my ability to get things working as needed. The first is that I didn't have root access. This was new to me and for those that deal with this on a daily basis you may find my annoyance funny.
The ViaVerio server has mod_perl (1.21) and apache (1.3.12) with mod_perl as a DSO. I thought great, I just install their mod_perl add the LoadModule and I am off.

I did that and it started, I had added perl-status to the httpd.conf so I looked to see if it was loading ok, everything looked ok. Then I started adding the modules I needed to make things run correctly. This is when the not being root really started to pain me. I couldn't use CPAN and I didn't know about the vcpan that Verio offers, but later when I tried the vcpan it seemed to give the same complaints, that is no permission to write to the main Perl directories.

GREAT! Ok lets go to the guide ( and see what to do. Well from that and the Verio documentation I learned how to install modules locally.

I created a file called 'perlset', this was used like so:

perl Makefile.PL `cat ../perlset`
perlset consisted of:
PREFIX=/usr/home/<username>/usr/local \ INSTALLPRIVLIB=/usr/home/<username>/usr/local/lib/perl5 \ INSTALLSCRIPT=/usr/home/<username>/usr/local/bin \ INSTALLSITELIB=/usr/home/<username>/usr/local/lib/perl5/site_perl \ INSTALLBIN=/usr/home/<username>/usr/local/bin \ INSTALLMAN1DIR=/usr/home/<username>/usr/local/lib/perl5/man \ INSTALLMAN3DIR=/usr/home/<username>/usr/local/lib/perl5/man/man3

That instructs the make process to do a local install versus a system wide install.

Then I realized module tests were failing because they didn't know about the additional local modules, so I created another file called perlenv. This file required different syntax based on shell, the one here is for the csh shell.

perlenv consisted of:
setenv PERL5LIB /usr/home/<username>/usr/local/lib/perl5: /usr/home/<username>/usr/local/lib/perl5/site_perl: /usr/home/<username>/usr/local/lib/site_perl

--- The above is ALL on one line inside the file ---

I verified the ability to install modules then added the above to my .cshrc file so that everytime I logged in it would be available.

So head way is being made. I got all my modules installed and now I was ready to preload inside of the httpd.conf so I could take advance of mod_perl. New set of problems.

It seem for some reason the Verio version of mod_perl couldn't load more then one module at a time and couldn't load some of them at all. I am not sure if it was a path issue, I had added the PERL5LIB setting inside of the httpd.conf under a PerlSetEnv directive, and I had tried adding use lib to the top of my file. I tried a <Perl> section and still no go. I contacted Verio support, they were not much help, I assume other people running mod_perl didn't have any problems or didn't need the stuff I did. I decided to run the site without preloading the modules to see if it would even work. Every request resulted in a Seg Fault. Ok, the guide says to run gdb and link the running process to get a back trace. That would be great if I had root access, since I couldn't link to a processing running as root.

Well I tried endless combinations trying to get it to load the modules or at least run the site, all to no avail.

Hmmm, what can I do? Well I never was one to just give up, and in this case not working under this server would cost the client a minimum of $200 extra a month. That would come directly out of the budget for site modifications, cutting off some of mine or another developers revenue stream. So I installed another copy of httpd with a static compile of mod_perl (not mentioned above, I attempted to recompile a newer version of mod_perl as a DSO following the 'guide', which compiled successfully, but still wouldn't deliver content). I used my standard .makepl_args.mod_perl changed a copy of paths and compiled everything beautifully. This is good, but I can't bind to port 80 because..., you guessed it, I am not root. Well just to test everything I setup on a port higher then 1024. I modified the httpd.conf and fired it up.


This was great. Now what to do about the port 80 issue. Being a shared server I couldn't ask to have mine run in place of the standard ones or at least that seemed to be the response of the Verio support people. Well the site designer I was working with came up with a great short term solution. We run the site in a frame and then redirect in that frame to the server running on the other port. That worked and we were able to move the site on schedule to its new home.

Now I know this is far from standard and there are hopefully better ways to deal with these issues, but this is just one way to get a good mod_perl environment on a shared server.

If others can offer me some knowledge on how to get the default Verio mod_perl working correctly please let me know. This solution (kludge) is working, but the client I am sure would prefer to have a standard port for its pages. UPDATE In doing another install I realized that if you have a correctly configured Perl install that allows each user to have its own module directory you can set the `cat perlset` arg for Makefile.PL inside of the file, just put the `cat perlset` (or equvilant) in the makepl_arg value.

Replies are listed 'Best First'.
Re: Perl/mod_perl on shared web servers
by lachoy (Parson) on Feb 14, 2002 at 05:26 UTC

    Unless you have a high traffic site, running mod_proxy works wonders. I don't know if it's feasible given your setup -- you can't restart the server to load the mod_proxy DSO -- but maybe they'll restart it for you. Or maybe it's already available.

    In a nutshell, you setup a pass-through on the server that's running now. It takes (all or some) requests on port 80 and passes them through to IP x port y. That process does what it needs to do then passes back the information to the proxy server, which passes it back to the client.

    The positives of this are that the backend can be anything on any port. Your statically-compiled mod_perl can run on with no problems since the port < 1024, and running on localhost is smart so nobody can get to it except through the proxy.

    The downsides are efficiency and complexity, although setting up mod_proxy is easy.

    This sort of setup is used often in the mod_perl world, but usually to save resources since the front-end servers can be lightweight (images, static files, etc.) and can save the interesting work for the heavyweight mod_perl servers. The mod_perl guide has more info about how to do this, along with discussion of other issues involved (headers, etc.)

    M-x auto-bs-mode

      Thanks. The file is already there. I will look into setting up with that thanks.

      UPDATE: Added mod_proxy and the two proxy lines as shown in the guide and all is transparent to the user.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://145367]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (2)
As of 2022-05-24 03:32 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (82 votes). Check out past polls.