perlmeditation
trs80
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)
<br>
<br>
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.<br>
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.
<br>
<br>
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.
<br>
<br>
GREAT! Ok lets go to the guide (http://perl.apache.org/guide/)
and see what to do. Well from that and the Verio
documentation I learned how to install modules locally.
<br>
<br>
I created a file called 'perlset', this was used like so:
<br>
<br>
perl Makefile.PL `cat ../perlset`
<br>
perlset consisted of:
<br>
<code>
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
</code>
<br>
<br>
That instructs the make process to do a local install versus
a system wide install.
<br>
<br>
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.<br>
<br>
perlenv consisted of:<br>
<code>
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
</code>
<br>
--- The above is ALL on one line inside the file ---
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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 perlstartup.pl 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.
<br>
<br>
Well I tried endless combinations trying to get it to load
the modules or at least run the site, all to no avail.
<br>
<br>
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.<br>
<br>
EVERYTHING WORKED!
<br>
<br> 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.
<br>
<br>
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.
<br>
<br>
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.
<b>UPDATE</b>
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 MyConfig.pm file, just put the `cat perlset` (or equvilant) in the makepl_arg value.