WHM Perl Module Locations @INC

SJR

Active Member
Jan 2, 2017
41
9
58
USA
cPanel Access Level
Website Owner
I am in the process of migrating from my current cPanel VPS to a new cPanel VPS.
My application is using Perl, and thus needs access to the Perl Modules. I have installed all the Perl Modules that are on my current VPS to the new VPS.
Many of the Perl Modules that are used in our application are in a directory in my cPanel account, in the cgi-bin directory:

home/abccompany/public_html/cgi-bin

When I test my application on the new vps I get an error message saying the Perl Modules in my cPanel account can't be located.
This makes sense because I haven't set the @INC environment to look in my cgi-bin directory.
This was done on my current server many years ago and the programmer that set this up is no longer around. I am a novice at much of this, so I need help.

On my current server, when I type command:
perl -e 'printf "%d %s\n", $i++, $_ for @INC'
I get:
root [/]# perl -e 'printf "%d %s\n", $i++, $_ for @INC'
0 /usr/local/lib64/perl5
1 /usr/local/share/perl5
2 /usr/lib64/perl5/vendor_perl
3 /usr/share/perl5/vendor_perl
4 /usr/lib64/perl5
5 /usr/share/perl5
6 .
root [/]# _

On the new server, when I type the same command, I get:
root [/]# perl -e 'printf "%d %s\n", $i++, $_ for @INC'
0 /usr/local/lib64/perl5
1 /usr/local/share/perl5
2 /usr/lib64/perl5/vendor_perl
3 /usr/share/perl5/vendor_perl
4 /usr/lib64/perl5
5 /usr/share/perl5
root [/]# _

As you can see, on the current server, line 6 is . (I'm not sure about the ( . ) but I think it is important because someone suggested it represents the 'current working directory' in my cPanel account. They suggested I run:
export PERL5LIB=.
When I tried this the server hung and nothing happened. When I ran the command above again, it is the same as before.

What command do I run, and where do I run it, to set the cgi-bin, or the 'current working directory' to be included in @INC?
Do I need to issue this command from a certain directory? Can this be done using cPanel's Terminal?

All help is greatly appreciated.
Thank you!
 

rbairwell

Well-Known Member
May 28, 2022
117
49
28
Mansfield, Nottingham, UK
cPanel Access Level
Root Administrator
When I tried this the server hung and nothing happened.
Did the entire server hang (i.e. no SSH access existing or new, no web pages etc) or did the existing SSH connection just hang? Was it straight after you typed that command? If so, I suspect that as you ran it as root it "screwed up" cPanel itself (which uses Perl).

Since you are trying to get Perl to work for a website, I would not be issuing these commands as root - but rather as the username of the hosting account for that website. Either login via SSH using their username or, from the root SSH, switch to their username using su - <username>. Depending on the server specific setups, paths for a particular user (and hence any scripts which run as the user) may be different from those provided to the root user (and, in fact, could be a different version of Perl)

  1. Are you running CloudLinux with CageFS? If so, I would update the cage before anything else.
  2. Is the list of Perl modules for the server identical on both servers (WHM->Software->Install a Perl Module) - if not, try installing then server wide (see "Installing a Perl Module from WHM" or "How to install a Perl module via the command line")
  3. Is the list of Perl modules for the user identical on both servers - see "Perl Modules" cPanel (as the user)->Software->Perl Modules. See also "How to use cPanel user installed Perl Modules"
  4. Does the Perl script work if you run perl scriptname.pl in the folder where the script is located as the user? (see "How can I create a test Perl script to confirm Perl is working?")
You say the error message reads "Perl Modules in my cPanel account can't be located". I don't believe that is the exact error message - could you let us know what the error message actually is (feel free to change any mention of your username, server name, IP address) as it'll give more guidance as to the problem.

Does the listing for @INC stay the same when you are logged in as the user on both servers (you might find using env -i perl -V quicker to show the list of paths) ?
Is the Perl version different on the server (Perl 5.26+ might not have the current working directory [.] set if it is running with taint checks enabled). Again, env -i perl -V will give the version.

If you really want them to match, you'll need to use the command:
Code:
export PERL5LIB=$PERL5LIB:.
The addition of the $PERL5LIB: section means it does not remove the existing paths (and hence shouldn't break anything). However, this will only work for the current session, you'll need to add it to the user's .bashrc file (~/.basrc) for it to persist.

I would recommend adding "use lib '/ home/abccompany/public_html/cgi-bin';" to the script instead of changing server variables.

Hope it helps!
 
  • Like
Reactions: SJR and cPRex

SJR

Active Member
Jan 2, 2017
41
9
58
USA
cPanel Access Level
Website Owner
Thank you rbairwell for your input.

When I said the server hung, the terminal window just didn't give any response after I entered export PERL5LIB=.
I expected something to return, but nothing did. I was able to close the window and continue. When I entered perl -e 'printf "%d %s\n", $i++, $_ for @INC' again, the response is always the same as the first time. Everything on the server is working as expected. I don't know if there is a specific way to test Perl to make sure it is working correctly or not.

Here is the error message that came back the first time I tried to run a Perl script:

Can't locate ABC/dothisnow.pm in @INC (you may need to install the ABC::dothisnow module) (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at /home/abccompany/public_html/cgi-bin/client_login.pl line 12.

BEGIN failed--compilation aborted at /home/abccompany/public_html/cgi-bin/client_login.pl line 12.

The script, client_login.pl was run from the cgi-bin directory, and the module dothisnow.pm is in the subdirectory ABC of the cgi-bin directory.
home/abccompany/public_html/cgi-bin/ABC/

The old server is using Perl v5.16.3, and the new is using v5.26.3.
I came across this which may be important here:


In v5.26 the 'current working directory' or "." is no longer included. They then suggest a few workarounds.

However, I like your suggestion to to add "use lib '/ home/abccompany/public_html/cgi-bin';" to the script, instead of trying to change server wide variables.
I read that "use lib '.';" will do the same thing when running the script from the same directory. Is there any difference between the path vs "."?

Another suggestion is to add "push @INC, '.';" to the script. This is a suggestion in the above linked article from metacpan.
They suggest:

BEGIN {
my $dir = "/some/trusted/directory";
chdir $dir or die "Can't chdir to $dir: $!\n";
# safe now
push @INC, '.';
}

use "Foo::Bar"; # may load /some/trusted/directory/Foo/Bar.pm
do "config.pl"; # may load /some/trusted/directory/config.pl

But again, this appears to try to change the server environment. I don't know if this would persist or not, or what other concerns this may present.
In my first post the current server script I ran showed the "." on line 6. But the new server doesn't show this. I assume it is due to the current working directory being removed from v5.26.
Maybe this is why my code works fine on the current, but not on the new vps.

So, that's where I am so far on this issue.

Thank you!