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 (http://perl.apache.org/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:
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:
--- 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 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.
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.
EVERYTHING WORKED!
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 MyConfig.pm file, just put the `cat perlset` (or equvilant) in the makepl_arg value.
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 (http://perl.apache.org/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 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.
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.
EVERYTHING WORKED!
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 MyConfig.pm file, just put the `cat perlset` (or equvilant) in the makepl_arg value.
Back to
Meditations